On Fri, Jul 18, 2025 at 01:04:56PM +0200, Alejandro Vallejo wrote:
> Hi,
>
> I like the new encapsulation, but I have a few questions.
>
> On Wed Jul 16, 2025 at 4:04 AM CEST, dmukhin wrote:
> > From: Denis Mukhin
> >
> > Introduce domain_console for grouping data structures used for integrating
On 2025-07-17 06:33, Juergen Gross wrote:
On 16.07.25 23:15, Jason Andryuk wrote:
Factor out the xenstore setup code into configure_xenstore(). This is
in preparation for handling already-introduced domains.
Signed-off-by: Jason Andryuk
---
tools/helpers/init-dom0less.c | 51 +++
On Thu, Jul 17, 2025 at 08:31:27AM +0100, Andrii Sultanov wrote:
> Following a similar change to amd_iommu struct, make two more structs
> take pci_sbdf_t directly instead of seg and bdf separately. This lets us
> drop several conversions from the latter to the former and simplifies
> several compa
On Thu, Jul 17, 2025 at 08:31:25AM +0100, Andrii Sultanov wrote:
> Following on from 250d87dc3ff9 ("x86/msi: Change __msi_set_enable() to
> take pci_sbdf_t"), make struct amd_iommu contain pci_sbdf_t directly
> instead of specifying seg+bdf separately and regenerating sbdf_t from them,
> which simp
On Wed, Jul 16, 2025 at 11:31:06AM -0700, Elliott Mitchell wrote:
> On Wed, Jul 16, 2025 at 07:47:48AM +, Anthoine Bourgeois wrote:
> > On Tue, Jul 15, 2025 at 12:19:34PM -0700, Elliott Mitchell wrote:
> > >On Tue, Jul 15, 2025 at 08:21:40AM +, Anthoine Bourgeois wrote:
> > >>
> > >> Thank
This moves the exception path to being out-of-line within the function, rather
than in the .fixup section, which improves backtraces.
Because the macro is used multiple times, the fault label needs declaring as
local.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: R
On 7/18/25 07:08, Nicola Vetrini wrote:
> On 2025-07-18 11:28, Dmytro Prokopchuk1 wrote:
>> On 7/18/25 12:17, Dmytro Prokopchuk wrote:
>>>
>>>
>>> On 7/18/25 08:31, Jan Beulich wrote:
On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>
>
> On 4/23/25 20:54, victorm.l...@amd.com wrote:
On Fri, 18 Jul 2025 09:19:17 +0200 Jürgen Groß wrote:
> On 17.07.25 16:29, Jakub Kicinski wrote:
> > On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
> >> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
> >> storms")
> >
> > Not entirely sure who you expe
On Fri Jul 18, 2025 at 5:41 PM CEST, Andrew Cooper wrote:
> On 18/07/2025 4:12 pm, Alejandro Vallejo wrote:
>> Otherwise compile-time errors ensue. It's a nonsensical configuration,
>> but it's supriously triggered in randconfig jobs.
>>
>> Fixes: 8b5b49ceb3d9("x86: don't include domctl and alike i
Switch to the new fields and constants.
In mwait_idle_probe(), exit early for non-Intel CPUs. intel_idle_ids[] is a
large (and ever increasing) table and it's not reasonable to scan it for other
vendors, nor is it ideal to be emitting an ambigous error(ish) message.
No practical change.
Signed-
This snapshot is Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines"), now that Xen has switched off the old constant
names.
Leave a comment identifying the exact revision Xen is using.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger P
Switch to the new fields and constants.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
I've intentionally not converted the tables with raw numbers yet. That's not
a mechanical change, and requires more care.
---
xen/arch/x86/spec_ctrl.c | 162 +++
Switch to the new fields and constants.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
This updates one related part in intel.c for ease of ordering subseuqent work.
---
xen/arch/x86/cpu-policy.c | 19 ---
xen/arch/x86/cpu/intel.c
This is a mechanical change to use the VFM constants rather than the
family-specific ones.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1934721940
Andrew Cooper (4):
x86/mwait-idle: Update vendor/family/model logic
x86/cpu-policy: Update vendor/family/model logic
x86/spec
On 18/07/2025 4:12 pm, Alejandro Vallejo wrote:
> Otherwise compile-time errors ensue. It's a nonsensical configuration,
> but it's supriously triggered in randconfig jobs.
>
> Fixes: 8b5b49ceb3d9("x86: don't include domctl and alike in shim-excl...")
> Signed-off-by: Alejandro Vallejo
> ---
> xe
On Wed, Jul 16, 2025 at 08:15:31PM +, Petr Beneš wrote:
> From: Petr Beneš
>
> Introduce a new altp2m_count parameter to control the maximum number of altp2m
> views a domain can use. By default, if altp2m_count is unspecified and altp2m
> is enabled, the value is set to 10, reflecting the le
Otherwise compile-time errors ensue. It's a nonsensical configuration,
but it's supriously triggered in randconfig jobs.
Fixes: 8b5b49ceb3d9("x86: don't include domctl and alike in shim-excl...")
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/Kconfig | 1 +
1 file changed, 1 insertion(+)
On 7/2/25 12:09 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Implement the mfn_valid() macro to verify whether a given MFN is valid by
checking that it falls within the range [start_page, max_page).
These bounds are initialized based on the start and end addresses of RAM.
On 7/2/25 12:28 PM, Jan Beulich wrote:
On 02.07.2025 12:09, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
@@ -613,3 +612,91 @@ void __iomem *ioremap(paddr_t pa, size_t len)
{
return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
}
+
+int page_is_ram_type(unsigned l
This is the next part of the VFM converstion, focusing on struct x86_cpu_id.
Some parts are already committed. See patches for details vs v1.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1934588566
Andrew Cooper (3):
x86/match-cpu: Improvements to x86_match_cpu()
x86/matc
Xen's use of struct x86_cpu_id is a bit different to Linux's, so we can
simplify the loop termination condition. Leave a comment explaining Xen's
assumptions.
Switch to Xen style, as we've properly devated from Linux, and switch to the
new vendor/family/model names.
No practical change.
Signed-
With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
helper to match a specific stepping, and use it to rework deadline_match[].
Currently, the table is scanned on all systems, even those without the
TSC_DEADLINE feature. Introduce another early exit for that case, which
remov
Architecturally, stepping is a 4-bit field, so a uint16_t suffices for a
bitmap of steppings.
In order to keep the size of struct x86_cpu_id the same, shrink the vendor and
family fields; there's no need for them to be uint16_t in Xen, and this
matches the size of the fields in cpuinfo_x86.
No fu
On 18.07.2025 13:47, Grygorii Strashko wrote:
>
>
> On 18.07.25 13:22, Jan Beulich wrote:
>> On 18.07.2025 12:11, Grygorii Strashko wrote:
>>> From: Grygorii Strashko
>>>
>>> Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
>>> arch callbacks become unreachable, so dro
On 18.07.2025 12:23, Andrew Cooper wrote:
> On 18/07/2025 11:19 am, Jan Beulich wrote:
>> On 18.07.2025 12:07, Andrew Cooper wrote:
>>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>>> helper to match a specific stepping, and use it to rework deadline_match[].
>>>
>>> No
On 18/07/2025 3:06 pm, Jan Beulich wrote:
> On 18.07.2025 12:55, Andrew Cooper wrote:
>> On 18/07/2025 11:23 am, Andrew Cooper wrote:
>>> On 18/07/2025 11:19 am, Jan Beulich wrote:
On 18.07.2025 12:07, Andrew Cooper wrote:
> With the ability to match on steppings, introduce a new X86_MATCH
On 18.07.2025 12:55, Andrew Cooper wrote:
> On 18/07/2025 11:23 am, Andrew Cooper wrote:
>> On 18/07/2025 11:19 am, Jan Beulich wrote:
>>> On 18.07.2025 12:07, Andrew Cooper wrote:
With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
helper to match a specific stepping
On 18/07/2025 2:28 pm, Jan Beulich wrote:
>> uint16_t model;
> Whereas the model is strictly limited to 8 bits.
There is space in here, if we need it, but you can't shrink it without
breaking the check for the NULL entry (going back to the first
obfuscation).
>>> Breaki
On 15.07.25 15:44, WangYuli wrote:
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Link:
https://lore.kernel.org/all/b3c019b63c93846f+20250715071245.398846-1-wangy...@uniontech.com/
Signed-off-by: WangYuli
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0x
On 18.07.2025 13:52, Mykyta Poturai wrote:
> On 16.07.25 11:36, Jan Beulich wrote:
>> On 16.07.2025 09:43, Mykyta Poturai wrote:
>>> Without pci-passthrough=on Xen does not know anything about present PCI
>>> devices due to PHYSDEVOP_pci_device_add not executing.
>>
>> While the latter half of the
On 18.07.2025 12:29, Andrew Cooper wrote:
> On 18/07/2025 6:53 am, Jan Beulich wrote:
>> On 17.07.2025 21:39, Andrew Cooper wrote:
>>> On 17/07/2025 9:11 am, Jan Beulich wrote:
On 16.07.2025 19:31, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
Daniel P. Berrangé writes:
> On Fri, Jul 18, 2025 at 07:59:50AM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> > Adam Williamson writes:
>> >
>> >> In cfcacba an `error_report` was added to this file, but the
>> >> corresponding include of `qemu/error-report.h` was missed.
On Fri, Jul 18, 2025 at 12:54:38PM +0200, David Hildenbrand wrote:
> On 18.07.25 12:41, Lorenzo Stoakes wrote:
> > On Thu, Jul 17, 2025 at 10:31:28PM +0200, David Hildenbrand wrote:
> > > On 17.07.25 20:29, Lorenzo Stoakes wrote:
> > > > On Thu, Jul 17, 2025 at 01:52:08PM +0200, David Hildenbrand w
On Fri, Jul 18, 2025 at 01:04:30PM +0200, David Hildenbrand wrote:
> >
> > Yeah sorry I was in 'what locks do we need' mode and hadn't shifted back
> > here,
> > but I guess the intent is that the caller _must_ hold this lock.
> >
> > I know it's nitty and annoying (sorry!) but as asserting seems
On Fri, Jul 18, 2025 at 01:06:30PM +0200, David Hildenbrand wrote:
> On 18.07.25 12:47, Lorenzo Stoakes wrote:
> > On Thu, Jul 17, 2025 at 10:14:33PM +0200, David Hildenbrand wrote:
> > > On 17.07.25 22:03, Lorenzo Stoakes wrote:
> > > > On Thu, Jul 17, 2025 at 01:52:11PM +0200, David Hildenbrand w
On Thu, Jul 17, 2025 at 10:03:44PM +0200, David Hildenbrand wrote:
> On 17.07.25 21:55, Lorenzo Stoakes wrote:
> > On Thu, Jul 17, 2025 at 08:51:51PM +0100, Lorenzo Stoakes wrote:
> > > > @@ -721,37 +772,21 @@ struct page *vm_normal_page_pmd(struct
> > > > vm_area_struct *vma, unsigned long addr,
On Thu, Jul 17, 2025 at 10:12:37PM +0200, David Hildenbrand wrote:
> > >
> > > -/*
> > > - * vm_normal_page -- This function gets the "struct page" associated
> > > with a pte.
> > > +/**
> > > + * vm_normal_page_pfn() - Get the "struct page" associated with a PFN in
> > > a
> > > + *
Add new alpine-based build that enables LibAFL-based fuzzer.
Use this new build to run two fuzzing sessions: hypercall fuzzing and
gicv2 fuzzing. Currently, this is all the fuzzing modes supported by
xen fuzzer. Every fuzzing session will run approximately 10 minutes.
Fuzzing session will provide
LibAFL, which is a part of AFL++ project is a instrument that allows
us to perform fuzzing on beremetal code (Xen hypervisor in this case)
using QEMU as an emulator. It employs QEMU's ability to create
snapshots to run many tests relatively quickly: system state is saved
right before executing a ne
It is possible to use LibAFL with LibAFL-QEMU to fuzz different
baremetal programs, including Xen hypervisor. This small series
tries to add minimal (but extenable) support for fuzzing.
changes in v4:
- No global changes, only minor changes in patches, see local
changelog.
changes in v3:
- A
On 18/07/2025 1:11 pm, Frediano Ziglio wrote:
> The function is similar to PrintStr with an implicit newline
> added to the string.
> In Xen this is not a common pattern and this is used in EFI
> ARM code only making it not much coherent with X86 code
> so use PrintStr directly to make the code mor
On 18/07/2025 1:00 pm, Frediano Ziglio wrote:
> On Fri, Jul 18, 2025 at 12:12 PM Andrew Cooper
> wrote:
>> On 18/07/2025 10:41 am, Frediano Ziglio wrote:
>>> PrintMessage function print a message string followed by a
>>> new line.
>>> Move the function from ARM specific code to common code.
>>> Re
The function is similar to PrintStr with an implicit newline
added to the string.
In Xen this is not a common pattern and this is used in EFI
ARM code only making it not much coherent with X86 code
so use PrintStr directly to make the code more coherent.
Signed-off-by: Frediano Ziglio
---
Changes
On Fri, Jul 18, 2025 at 12:12 PM Andrew Cooper
wrote:
>
> On 18/07/2025 10:41 am, Frediano Ziglio wrote:
> > PrintMessage function print a message string followed by a
> > new line.
> > Move the function from ARM specific code to common code.
> > Reuse it in EFI code.
> > No functional changes.
>
On 16.07.25 11:36, Jan Beulich wrote:
> On 16.07.2025 09:43, Mykyta Poturai wrote:
>> Without pci-passthrough=on Xen does not know anything about present PCI
>> devices due to PHYSDEVOP_pci_device_add not executing.
>
> While the latter half of the sentence is true, Xen may know of PCI devices
> b
On 18.07.25 13:22, Jan Beulich wrote:
On 18.07.2025 12:11, Grygorii Strashko wrote:
From: Grygorii Strashko
Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
arch callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/arm/irq.
On 17.07.25 16:03, Jan Beulich wrote:
On 17.07.2025 14:58, Grygorii Strashko wrote:
On 23.06.25 21:28, dm...@proton.me wrote:
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2080,17 +2080,17 @@ void __init create_dom0(void)
dom0 = domain_create(domid, &dom0
On 7/17/25 12:37 PM, Jan Beulich wrote:
On 17.07.2025 11:42, Oleksii Kurochko wrote:
On 7/16/25 6:12 PM, Jan Beulich wrote:
On 16.07.2025 17:53, Oleksii Kurochko wrote:
On 7/16/25 1:43 PM, Jan Beulich wrote:
On 16.07.2025 13:32, Oleksii Kurochko wrote:
On 7/2/25 10:35 AM, Jan Beulich wrote:
On 18/07/2025 10:41 am, Frediano Ziglio wrote:
> PrintMessage function print a message string followed by a
> new line.
> Move the function from ARM specific code to common code.
> Reuse it in EFI code.
> No functional changes.
>
> Signed-off-by: Frediano Ziglio
Please no.
Hiding \n (or \r\n) in
On Thu Jul 17, 2025 at 9:58 PM CEST, dmkhn wrote:
> On Thu, Jul 17, 2025 at 05:43:22PM +0200, Alejandro Vallejo wrote:
>> On Tue Jun 24, 2025 at 9:24 AM CEST, dmkhn wrote:
>> > On Tue, Jun 24, 2025 at 08:13:08AM +0200, Orzel, Michal wrote:
>> >>
>> >>
>> >> On 24/06/2025 05:55, dm...@proton.me wrot
On 2025-07-18 11:28, Dmytro Prokopchuk1 wrote:
On 7/18/25 12:17, Dmytro Prokopchuk wrote:
On 7/18/25 08:31, Jan Beulich wrote:
On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
On 4/23/25 20:54, victorm.l...@amd.com wrote:
From: Nicola Vetrini
MISRA C Rules 21.1 ("#define and #undef shall
On 18.07.25 12:47, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 10:14:33PM +0200, David Hildenbrand wrote:
On 17.07.25 22:03, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 01:52:11PM +0200, David Hildenbrand wrote:
Let's introduce vm_normal_page_pud(), which ends up being fairly simple
beca
Yeah sorry I was in 'what locks do we need' mode and hadn't shifted back here,
but I guess the intent is that the caller _must_ hold this lock.
I know it's nitty and annoying (sorry!) but as asserting seems to not be a
possibility here, could we spell these out as a series of points like:
/*
Hi,
I like the new encapsulation, but I have a few questions.
On Wed Jul 16, 2025 at 4:04 AM CEST, dmukhin wrote:
> From: Denis Mukhin
>
> Introduce domain_console for grouping data structures used for integrating
> domain's diagnostic console with Xen's console driver.
>
> Group all pbuf-relat
On 18/07/2025 11:23 am, Andrew Cooper wrote:
> On 18/07/2025 11:19 am, Jan Beulich wrote:
>> On 18.07.2025 12:07, Andrew Cooper wrote:
>>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>>> helper to match a specific stepping, and use it to rework deadline_match[].
>>>
>>>
On 18.07.25 12:41, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 10:31:28PM +0200, David Hildenbrand wrote:
On 17.07.25 20:29, Lorenzo Stoakes wrote:
On Thu, Jul 17, 2025 at 01:52:08PM +0200, David Hildenbrand wrote:
The huge zero folio is refcounted (+mapcounted -- is that a word?)
different
On 7/15/2025 3:44 PM, WangYuli wrote:
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Link:https://lore.kernel.org/all/B3C019B63C93846F+20250715071245.398846-1-
wangy...@uniontech.com/
I think it has been said on other patches but it is not common to link
On Thu, Jul 17, 2025 at 10:14:33PM +0200, David Hildenbrand wrote:
> On 17.07.25 22:03, Lorenzo Stoakes wrote:
> > On Thu, Jul 17, 2025 at 01:52:11PM +0200, David Hildenbrand wrote:
> > > Let's introduce vm_normal_page_pud(), which ends up being fairly simple
> > > because of our new common helpers
On Thu, Jul 17, 2025 at 10:31:28PM +0200, David Hildenbrand wrote:
> On 17.07.25 20:29, Lorenzo Stoakes wrote:
> > On Thu, Jul 17, 2025 at 01:52:08PM +0200, David Hildenbrand wrote:
> > > The huge zero folio is refcounted (+mapcounted -- is that a word?)
> > > differently than "normal" folios, simi
On 18.07.2025 12:11, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
> arch callbacks become unreachable, so drop them.
>
> Signed-off-by: Grygorii Strashko
> ---
> xen/arch/arm/irq.c | 29 --
On 18/07/2025 6:53 am, Jan Beulich wrote:
> On 17.07.2025 21:39, Andrew Cooper wrote:
>> On 17/07/2025 9:11 am, Jan Beulich wrote:
>>> On 16.07.2025 19:31, Andrew Cooper wrote:
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -1003,13 +1003,15 @@ const struct x86_cp
On 18/07/2025 11:19 am, Jan Beulich wrote:
> On 18.07.2025 12:07, Andrew Cooper wrote:
>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>> helper to match a specific stepping, and use it to rework deadline_match[].
>>
>> Notably this removes the overloading of driver_data
On 18.07.2025 12:07, Andrew Cooper wrote:
> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
> helper to match a specific stepping, and use it to rework deadline_match[].
>
> Notably this removes the overloading of driver_data possibly being a function
> pointer, and remove
On Thu, Jul 17, 2025 at 10:03:31PM +0200, David Hildenbrand wrote:
> > > The report will now look something like (dumping pgd to pmd values):
> > >
> > > [ 77.943408] BUG: Bad page map in process XXX entry:8001233f5867
> > > [ 77.944077] addr:7fd84bb1c000 vm_flags:08100071 anon_vma: ..
From: Grygorii Strashko
The dump_p2m_lookup() is not used, so remove it.
Signed-off-by: Grygorii Strashko
---
xen/arch/arm/include/asm/page.h | 2 --
xen/arch/arm/mmu/p2m.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/xen/arch/arm/include/asm/page.h b/xen/arch/a
From: Grygorii Strashko
On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
functions are unreachable (Misra rule 2.1).
Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule 2.1
violation and resolve call of evtchn_move_pirqs() from common /sched/core.c
vcpu_move
From: Grygorii Strashko
Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
arch callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/arm/irq.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/xen/arc
On 18.07.2025 11:17, Dmytro Prokopchuk1 wrote:
> On 7/18/25 08:31, Jan Beulich wrote:
>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>> I tried to play with Rule 21.1 deviations.
>>>
>>> After applying the following configurations:
>>>
>>> -config=MC3A2.R21.1,macros+={safe, "^offsetof$ || ^(is|
With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
helper to match a specific stepping, and use it to rework deadline_match[].
Notably this removes the overloading of driver_data possibly being a function
pointer, and removes the latent bug where the target functions are miss
On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko wrote:
On 7/16/25 6:18 PM, Jan Beulich wrote:
On 16.07.2025 18:07, Oleksii Kurochko wrote:
On 7/16/25 1:31 PM, Jan Beulich wrote:
On 15.07.2025 16:47, Oleksii Kurochko wrote:
On 7/1/25 5:08 PM, Jan Beulich wrote:
On Fri Jul 18, 2025 at 8:42 AM CEST, Jan Beulich wrote:
> On 18.07.2025 02:04, Stefano Stabellini wrote:
>> On Thu, 17 Jul 2025, Jason Andryuk wrote:
>>> On 2025-07-17 13:51, Alejandro Vallejo wrote:
Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
behaviour on any hwdom/
PrintMessage function print a message string followed by a
new line.
Move the function from ARM specific code to common code.
Reuse it in EFI code.
No functional changes.
Signed-off-by: Frediano Ziglio
---
xen/arch/arm/efi/efi-boot.h | 7 ---
xen/arch/x86/efi/efi-boot.h | 2 +-
xen/common/
On 7/18/25 12:17, Dmytro Prokopchuk wrote:
>
>
> On 7/18/25 08:31, Jan Beulich wrote:
>> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 4/23/25 20:54, victorm.l...@amd.com wrote:
From: Nicola Vetrini
MISRA C Rules 21.1 ("#define and #undef shall not be used on a
>
On 7/18/25 08:31, Jan Beulich wrote:
> On 17.07.2025 22:47, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 4/23/25 20:54, victorm.l...@amd.com wrote:
>>> From: Nicola Vetrini
>>>
>>> MISRA C Rules 21.1 ("#define and #undef shall not be used on a
>>> reserved identifier or reserved macro name") and R21.2
ARINC653 specificaion requires partition scheduling to be deterministic
and periodic over time.
However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism an
On Fri, Jul 18, 2025 at 07:59:50AM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Adam Williamson writes:
> >
> >> In cfcacba an `error_report` was added to this file, but the
> >> corresponding include of `qemu/error-report.h` was missed. This
> >> only becomes apparent when
On 18.07.25 09:59, Demi Marie Obenour wrote:
On 7/18/25 03:44, David Hildenbrand wrote:
On 18.07.25 00:06, Demi Marie Obenour wrote:
On 7/17/25 07:52, David Hildenbrand wrote:
print_bad_pte() looks like something that should actually be a WARN
or similar, but historically it apparently has pro
On Thu, Jul 17, 2025 at 07:29:51AM -0700, Jakub Kicinski wrote:
>On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
>> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
>> storms")
>
>Not entirely sure who you expect to apply this patch, but if networking
>then I
On 7/18/25 03:44, David Hildenbrand wrote:
> On 18.07.25 00:06, Demi Marie Obenour wrote:
>> On 7/17/25 07:52, David Hildenbrand wrote:
>>> print_bad_pte() looks like something that should actually be a WARN
>>> or similar, but historically it apparently has proven to be useful to
>>> detect corrup
On 18.07.25 00:06, Demi Marie Obenour wrote:
On 7/17/25 07:52, David Hildenbrand wrote:
print_bad_pte() looks like something that should actually be a WARN
or similar, but historically it apparently has proven to be useful to
detect corruption of page tables even on production systems -- report
On 17.07.25 16:29, Jakub Kicinski wrote:
On Tue, 15 Jul 2025 16:11:29 + Anthoine Bourgeois wrote:
Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel
storms")
Not entirely sure who you expect to apply this patch, but if networking
then I wouldn't classify this is a f
81 matches
Mail list logo
