Re: [PATCH 10/22] x86/mapcache: initialise the mapcache for the idle domain

2024-01-10 Thread Jan Beulich
On 10.01.2024 17:24, Elias El Yandouzi wrote: > On 22/12/2022 13:06, Jan Beulich wrote: >> On 16.12.2022 12:48, Julien Grall wrote: >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -5963,6 +5963,9 @@ int create_perdomain_mapping(struct domain *d, >>> unsigned long va, >>> l

Re: [PATCH 1/2] x86/vmx: Fix IRQ handling for EXIT_REASON_INIT

2024-01-10 Thread Jan Beulich
On 10.01.2024 20:11, Andrew Cooper wrote: > On 02/11/2023 8:57 am, Jan Beulich wrote: >> On 01.11.2023 20:20, Andrew Cooper wrote: >>> --- a/xen/arch/x86/hvm/vmx/vmx.c >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c >>> @@ -4097,10 +4097,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) >>> case E

[PATCH 8/8] x86/APIC: drop regs parameter from direct vector handler functions

2024-01-10 Thread Jan Beulich
The only place it was needed is in the spurious handler, and there we can use get_irq_regs() instead. Signed-off-by: Jan Beulich --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -1324,7 +1324,7 @@ int reprogram_timer(s_time_t timeout) return apic_tmict || !timeout; } -static void c

[PATCH 7/8] x86/vPMU: drop regs parameter from interrupt functions

2024-01-10 Thread Jan Beulich
The vendor functions don't use the respective parameters at all. In vpmu_do_interrupt() there's only a very limited area where the outer context's state would be needed, retrievable by get_irq_regs(). This is in preparation of dropping the register parameters from direct APIC vector handler functi

[PATCH 6/8] IRQ: drop register parameter from handler functions

2024-01-10 Thread Jan Beulich
It's simply not needed anymore. Note how Linux made this change many years ago already, in 2.6.19 (late 2006, see [1]). Signed-off-by: Jan Beulich [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=7d12e780e003f93433d49ce78cfedf4b4c52adc5 --- a/xen/arch/arm/gic.c

[PATCH 5/8] serial: drop serial_[rt]x_interrupt()'s regs parameter

2024-01-10 Thread Jan Beulich
In the the polling functions (ab)using set_irq_regs() is necessary to balance the change. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich --- a/xen/drivers/char/cadence-uart.c +++ b/xen/drivers/char/cadence-uart.c @@ -51,7 +51,7 @

[PATCH 4/8] PV-shim: drop pv_console_rx()'s regs parameter

2024-01-10 Thread Jan Beulich
It's not needed anymore. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich --- a/xen/arch/x86/guest/xen/xen.c +++ b/xen/arch/x86/guest/xen/xen.c @@ -181,7 +181,7 @@ static void cf_check xen_evtchn_upcall(s port += l1 *

[PATCH 3/8] serial: drop serial_rx_fn's regs parameter

2024-01-10 Thread Jan Beulich
In the one place where it's needed, get_irq_regs() can be used instead. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -527,12 +527,12 @@ static void switch_ser

[PATCH 2/8] IRQ: generalize [gs]et_irq_regs()

2024-01-10 Thread Jan Beulich
Move functions (and their data) to common code, and invoke the functions on Arm as well. This is in preparation of dropping the register parameters from handler functions. Signed-off-by: Jan Beulich --- To limit visibility of the per-CPU data item, we may want to consider making the functions out

[PATCH 1/8] keyhandler: don't pass cpu_user_regs around

2024-01-10 Thread Jan Beulich
There are exactly two handlers which care about the registers. Have handle_keypress() make the pointer available via a per-CPU variable, thus eliminating the need to pass it to all IRQ key handlers, making sure that a console-invoked key's handling can still nest inside a sysctl-invoked one's. Sig

[PATCH 0/8] limit passing around of cpu_user_regs

2024-01-10 Thread Jan Beulich
Unlike (synchronous) exception handlers, interrupt handlers don't normally have a need to know the outer context's register state. Similarly, the vast majority of key handlers has no need for such. 1: keyhandler: don't pass cpu_user_regs around 2: IRQ: generalize [gs]et_irq_regs() 3: serial: drop

Re: [PATCH 0/8] limit passing around of cpu_user_regs

2024-01-10 Thread Jan Beulich
On 11.01.2024 08:21, Jan Beulich wrote: > Unlike (synchronous) exception handlers, interrupt handlers don't normally > have a need to know the outer context's register state. Similarly, the vast > majority of key handlers has no need for such. > > 1: keyhandler: don't pass cpu_user_regs around > 2

[PATCH 4/8] PV-shim: drop pv_console_rx()'s regs parameter

2024-01-10 Thread Jan Beulich
It's not needed anymore. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich --- a/xen/arch/x86/guest/xen/xen.c +++ b/xen/arch/x86/guest/xen/xen.c @@ -181,7 +181,7 @@ static void cf_check xen_evtchn_upcall(s port += l1 *

[PATCH 3/8] serial: drop serial_rx_fn's regs parameter

2024-01-10 Thread Jan Beulich
In the one place where it's needed, get_irq_regs() can be used instead. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -527,12 +527,12 @@ static void switch_ser

[PATCH 2/8] IRQ: drop register parameter from handler functions

2024-01-10 Thread Jan Beulich
It's simply not needed anymore. Note how Linux made this change many years ago already, in 2.6.19 (late 2006, see [1]). Signed-off-by: Jan Beulich [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=7d12e780e003f93433d49ce78cfedf4b4c52adc5 --- a/xen/arch/arm/gic.c

[PATCH 1/8] limit passing around of cpu_user_regs

2024-01-10 Thread Jan Beulich
There are exactly two handlers which care about the registers. Have handle_keypress() make the pointer available via a per-CPU variable, thus eliminating the need to pass it to all IRQ key handlers, making sure that a console-invoked key's handling can still nest inside a sysctl-invoked one's. Sig

[PATCH 0/8] limit passing around of cpu_user_regs

2024-01-10 Thread Jan Beulich
Unlike (synchronous) exception handlers, interrupt handlers don't normally have a need to know the outer context's register state. Similarly, the vast majority of key handlers has no need for such. 1: keyhandler: don't pass cpu_user_regs around 2: IRQ: generalize [gs]et_irq_regs() 3: serial: drop

[linux-5.4 test] 184306: regressions - FAIL

2024-01-10 Thread osstest service owner
flight 184306 linux-5.4 real [real] flight 184317 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184306/ http://logs.test-lab.xenproject.org/osstest/logs/184317/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

E820 memory allocation issue on Threadripper platforms

2024-01-10 Thread Patrick Plenefisch
Hi, I ran into a memory allocation issue, I think. It is the same as https://github.com/QubesOS/qubes-issues/issues/8791 and I saw at the end it was recommended (by marmarek) that the issue reporter forward the issue to this list. I searched the list, but as I didn't see it in the list already, I'

[ovmf test] 184315: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184315 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184315/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 889535caf8869e3d4818b75f95f2fc910c84a4d2 baseline version: ovmf e7cfdc5f14b408e85fcbc

[linux-linus test] 184303: regressions - FAIL

2024-01-10 Thread osstest service owner
flight 184303 linux-linus real [real] flight 184313 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184303/ http://logs.test-lab.xenproject.org/osstest/logs/184313/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

Re: [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission

2024-01-10 Thread Chen, Jiqian
On 2024/1/11 04:09, Stewart Hildebrand wrote: > On 1/5/24 02:09, Jiqian Chen wrote: >> diff --git a/xen/common/domctl.c b/xen/common/domctl.c >> index f5a71ee5f78d..eeb975bd0194 100644 >> --- a/xen/common/domctl.c >> +++ b/xen/common/domctl.c >> @@ -653,12 +653,20 @@ long do_domctl(XEN_GUEST_HANDLE

Re: [RFC XEN PATCH v4 1/5] xen/vpci: Clear all vpci status of device

2024-01-10 Thread Chen, Jiqian
On 2024/1/10 22:09, Stewart Hildebrand wrote: > On 1/10/24 01:24, Chen, Jiqian wrote: >> On 2024/1/9 23:24, Stewart Hildebrand wrote: >>> On 1/5/24 02:09, Jiqian Chen wrote: diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c index 42db3e6d133c..552ccbf747cb 100644 ---

[libvirt test] 184301: tolerable FAIL - PUSHED

2024-01-10 Thread osstest service owner
flight 184301 libvirt real [real] flight 184312 libvirt real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184301/ http://logs.test-lab.xenproject.org/osstest/logs/184312/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-li

Re: [PATCH v3 29/33] tools/xenstored: map stubdom interface

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:03 AM Juergen Gross wrote: > > When running as stubdom, map the stubdom's Xenstore ring page in order > to support using the 9pfs frontend. > > Use the same pattern as in dom0_init() when running as daemon in dom0 > (introduce the own domain, then send an event to the clie

Re: [PATCH v3 28/33] tools/xenstored: split domain_init()

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:59 AM Juergen Gross wrote: > > Today domain_init() is called either just before calling dom0_init() > in case no live update is being performed, or it is called after > reading the global state from read_state_global(), as the event > channel fd is needed. > > Split up dom

Re: [PATCH v3 26/33] tools/xenstored: get own domid in stubdom case

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:34 AM Juergen Gross wrote: > > Obtain the own domid when running as stubdom. Maybe "Obtain own domid when running as stubdom."? > > Signed-off-by: Juergen Gross Reviewed-by: Jason Andryuk

Re: [PATCH v3 25/33] tools/xenstored: move all socket handling into posix.c

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:10 AM Juergen Gross wrote: > > All of the socket handling is needed only when running as daemon. > > Move it into posix.c, allowing to remove the NO_SOCKETS macro. > > Signed-off-by: Juergen Gross Reviewed-by: Jason Andryuk

Re: [PATCH v3 24/33] tools/xenstored: move all log-pipe handling into posix.c

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:11 AM Juergen Gross wrote: > > All of the log-pipe handling is needed only when running as daemon. > > Move it into posix.c. This requires to have a service function in the > main event loop for handling the related requests and one for setting > the fds[] array. Use a gen

Re: [PATCH v3 23/33] tools/xenstored: move systemd handling to posix.c

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:13 AM Juergen Gross wrote: > > Move systemd handling to a new late_init() function in posix.c. > > This prepares a future removal of the NO_SOCKETS macro. > > Signed-off-by: Juergen Gross Reviewed-by: Jason Andryuk

Re: [PATCH for-4.18 v1] xen/common: Don't dereference overlay_node after checking that it is NULL

2024-01-10 Thread Vikram Garhwal
Hi Javi, Thank you for spotting and fixing this. On Tue, Jan 09, 2024 at 03:31:55PM +, Julien Grall wrote: > Hi Javi, > > Title: Any reason this is titled for-4.18? Shouldn't this patch also be > merged in staging? > > On 09/01/2024 14:19, Javi Merino wrote: > > In remove_nodes(), overlay_nod

Re: [PATCH v3 22/33] tools/xenstored: add early_init() function

2024-01-10 Thread Jason Andryuk
On Thu, Jan 4, 2024 at 4:12 AM Juergen Gross wrote: > > Some xenstored initialization needs to be done in the daemon case only, > so split it out into a new early_init() function being a stub in the > stubdom case. > > Remove the call of talloc_enable_leak_report_full(), as it serves no > real pur

Re: [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission

2024-01-10 Thread Stewart Hildebrand
On 1/5/24 02:09, Jiqian Chen wrote: > diff --git a/xen/common/domctl.c b/xen/common/domctl.c > index f5a71ee5f78d..eeb975bd0194 100644 > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -653,12 +653,20 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) > u_domctl) > unsigned

Re: [PATCH 1/2] x86/vmx: Fix IRQ handling for EXIT_REASON_INIT

2024-01-10 Thread Andrew Cooper
On 02/11/2023 8:57 am, Jan Beulich wrote: > On 01.11.2023 20:20, Andrew Cooper wrote: >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -4097,10 +4097,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) >> case EXIT_REASON_MCE_DURING_VMENTRY: >> do_mac

[ovmf test] 184310: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184310 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184310/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e7cfdc5f14b408e85fcbcb335aae7c15bbce4dfb baseline version: ovmf 7d055812cc7a7d2b062cf

Re: [PATCH] x86/nmi: ensure Global Performance Counter Control is setup correctly

2024-01-10 Thread Andrew Cooper
On 10/01/2024 4:58 pm, Roger Pau Monné wrote: > On Wed, Jan 10, 2024 at 03:52:49PM +, Andrew Cooper wrote: >> On 10/01/2024 3:34 pm, Roger Pau Monne wrote: >>> When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL >>> MSR contains per-counter enable bits that is ANDed wit

Re: [PATCH] x86/nmi: ensure Global Performance Counter Control is setup correctly

2024-01-10 Thread Roger Pau Monné
On Wed, Jan 10, 2024 at 03:52:49PM +, Andrew Cooper wrote: > On 10/01/2024 3:34 pm, Roger Pau Monne wrote: > > When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL > > MSR contains per-counter enable bits that is ANDed with the enable bit in > > the > > counter EVNTSEL

[xen-unstable test] 184299: tolerable FAIL - PUSHED

2024-01-10 Thread osstest service owner
flight 184299 xen-unstable real [real] flight 184309 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184299/ http://logs.test-lab.xenproject.org/osstest/logs/184309/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

Re: [PATCH 10/22] x86/mapcache: initialise the mapcache for the idle domain

2024-01-10 Thread Elias El Yandouzi
Hi, On 22/12/2022 13:06, Jan Beulich wrote: On 16.12.2022 12:48, Julien Grall wrote: From: Hongyan Xia In order to use the mapcache in the idle domain, we also have to populate its page tables in the PERDOMAIN region, and we need to move mapcache_domain_init() earlier in arch_domain_create().

Re: xenpm cpufrequency settings don't work

2024-01-10 Thread flamv3421
I meant the xenpm get-cpufreq-average result did not match with what I had set as the maximum scaling frequency with xenpm and there are even times where the average is at 3GHz while my maximum scaling frequency is set to 80. Even if it was accurate, I believe there is something wrong with p

[ovmf test] 184307: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184307 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184307/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7d055812cc7a7d2b062cf56291211e8cecca36ed baseline version: ovmf bc34a79cd2a005e1d12d4

Re: [PATCH] x86/nmi: ensure Global Performance Counter Control is setup correctly

2024-01-10 Thread Andrew Cooper
On 10/01/2024 3:34 pm, Roger Pau Monne wrote: > When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL > MSR contains per-counter enable bits that is ANDed with the enable bit in the > counter EVNTSEL MSR in order for a PMC counter to be enabled. > > So far the watchdog code s

[PATCH] x86/nmi: ensure Global Performance Counter Control is setup correctly

2024-01-10 Thread Roger Pau Monne
When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL MSR contains per-counter enable bits that is ANDed with the enable bit in the counter EVNTSEL MSR in order for a PMC counter to be enabled. So far the watchdog code seems to have relied on the PERF_GLOBAL_CTRL enable bits

[xtf test] 184308: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184308 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184308/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf f3bd152f5e83da943535f6ba7b5772d4dbe96717 baseline version: xtf 837f771d9612215d5e6c9a

Re: [PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Roger Pau Monné
On Wed, Jan 10, 2024 at 03:47:12PM +0200, Xenia Ragiadakou wrote: > > > On 10/1/24 12:26, Jan Beulich wrote: > > On 10.01.2024 10:53, Roger Pau Monne wrote: > > > The HVM pirq feature allows routing interrupts from both physical and > > > emulated > > > devices over event channels, this was done

Re: [PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Andrew Cooper
On 10/01/2024 10:26 am, Jan Beulich wrote: > On 10.01.2024 10:53, Roger Pau Monne wrote: >> The HVM pirq feature allows routing interrupts from both physical and >> emulated >> devices over event channels, this was done a performance improvement. >> However >> its usage is fully undocumented, an

[PATCH v5 5/5] x86/vIRQ: split PCI link load state checking from actual loading

2024-01-10 Thread Jan Beulich
Move the checking into a check hook, and add checking of the padding fields as well. Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné --- v4: New. --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -749,6 +749,30 @@ static int cf_check irq_load_isa(struct return 0; } +s

[PATCH v5 4/5] x86/vPIC: check values loaded from state save record

2024-01-10 Thread Jan Beulich
Loading is_master from the state save record can lead to out-of-bounds accesses via at least the two container_of() uses by vpic_domain() and __vpic_lock(). Make sure the value is consistent with the instance being loaded. For ->int_output (which for whatever reason isn't a 1-bit bitfield), beside

[PATCH v5 3/5] x86/vPIT: check values loaded from state save record

2024-01-10 Thread Jan Beulich
In particular pit_latch_status() and speaker_ioport_read() perform calculations which assume in-bounds values. Several of the state save record fields can hold wider ranges, though. Refuse to load values which cannot result from normal operation, except mode, the init state of which (see also below

[PATCH v5 2/5] x86/HVM: adjust save/restore hook registration for optional check handler

2024-01-10 Thread Jan Beulich
Register NULL uniformly as a first step. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper --- v2: New. --- a/xen/arch/x86/cpu/mcheck/vmce.c +++ b/xen/arch/x86/cpu/mcheck/vmce.c @@ -374,7 +374,7 @@ static int cf_check vmce_load_vcpu_ctxt( return err ?: vmce_restore_vcpu(v, &ctxt); } -H

[PATCH v5 1/5] x86/HVM: split restore state checking from state loading

2024-01-10 Thread Jan Beulich
..., at least as reasonably feasible without making a check hook mandatory (in particular strict vs relaxed/zero-extend length checking can't be done early this way). Note that only one of the two uses of "real" hvm_load() is accompanied with a "checking" one. The other directly consumes hvm_save(

[PATCH v5 0/5] x86/HVM: load state checking

2024-01-10 Thread Jan Beulich
With the request to convert bounding to actual refusal, and then doing so in new hooks, the two previously separate patches now need to be in a series, with infrastructure work done first. Clearly the checking in other load handlers could (and likely wants to be) moved to separate check handlers as

[PATCH v3] NUMA: limit first_valid_mfn exposure

2024-01-10 Thread Jan Beulich
Address the TODO regarding first_valid_mfn by making the variable static when NUMA=y, thus also addressing a Misra C:2012 rule 8.4 concern (on x86). To carry this out, introduce two new IS_ENABLED()-like macros conditionally inserting "static". One less macro expansion layer is sufficient though (I

Re: [PATCH 6/6] xen/x86: Add topology generator

2024-01-10 Thread Jan Beulich
On 10.01.2024 15:16, Alejandro Vallejo wrote: > Review-to-self after running in Gitlab: > > On 09/01/2024 15:38, Alejandro Vallejo wrote: >> +p->basic.lppp = 0xff; >> +if ( threads_per_pkg < 0xff ) >> +p->basic.lppp = threads_per_pkg; >> + >> +switch ( p->x86_vendor ) >> +{

Re: [PATCH 6/6] xen/x86: Add topology generator

2024-01-10 Thread Alejandro Vallejo
Review-to-self after running in Gitlab: On 09/01/2024 15:38, Alejandro Vallejo wrote: > +p->basic.lppp = 0xff; > +if ( threads_per_pkg < 0xff ) > +p->basic.lppp = threads_per_pkg; > + > +switch ( p->x86_vendor ) > +{ > +case X86_VENDOR_INTEL: > +struct c

Re: [RFC XEN PATCH v4 1/5] xen/vpci: Clear all vpci status of device

2024-01-10 Thread Stewart Hildebrand
On 1/10/24 01:24, Chen, Jiqian wrote: > On 2024/1/9 23:24, Stewart Hildebrand wrote: >> On 1/5/24 02:09, Jiqian Chen wrote: >>> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c >>> index 42db3e6d133c..552ccbf747cb 100644 >>> --- a/xen/drivers/pci/physdev.c >>> +++ b/xen/drivers/pc

Re: [PATCH 1/2] libxl: Remove cdrom forced QDISK w/ stubdom

2024-01-10 Thread Marek Marczykowski-Górecki
On Tue, Jan 09, 2024 at 03:46:54PM -0500, Jason Andryuk wrote: > A Linux HVM domain ignores PV block devices with type cdrom. The > Windows PV drivers also ignore device-type != "disk". Therefore QEMU's > emulated CD-ROM support is used. This allows ejection and other CD-ROM > features to work.

Re: [PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Xenia Ragiadakou
On 10/1/24 12:26, Jan Beulich wrote: On 10.01.2024 10:53, Roger Pau Monne wrote: The HVM pirq feature allows routing interrupts from both physical and emulated devices over event channels, this was done a performance improvement. However its usage is fully undocumented, and the only referenc

Re: [PATCH 08/22] x86/pv: rewrite how building PV dom0 handles domheap mappings

2024-01-10 Thread El Yandouzi, Elias
Hi Jan, I have been looking at this series recently and tried my best to address your comments. I'll shortly to the other patches too. On 22/12/2022 11:48, Jan Beulich wrote: On 16.12.2022 12:48, Julien Grall wrote: From: Hongyan Xia Building a PV dom0 is allocating from the domheap but uses

Re: [PATCH v6 07/11] virtio-gpu: Handle resource blob commands

2024-01-10 Thread Pierre-Eric Pelloux-Prayer
Le 21/12/2023 à 09:09, Akihiko Odaki a écrit : On 2023/12/19 16:53, Huang Rui wrote: From: Antonio Caggiano Support BLOB resources creation, mapping and unmapping by calling the new stable virglrenderer 0.10 interface. Only enabled when available and via the blob config. E.g. -device virtio

[PATCH v2] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Roger Pau Monne
The HVM pirq feature allows routing interrupts from both physical and emulated devices over event channels, this was done a performance improvement. However its usage is fully undocumented, and the only reference implementation is in Linux. It defeats the purpose of local APIC hardware virtualiza

[ovmf test] 184305: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184305 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184305/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bc34a79cd2a005e1d12d4b05bec6efc3b102cad6 baseline version: ovmf 265b4ab91b8a31d6d1760

[linux-5.4 test] 184298: regressions - FAIL

2024-01-10 Thread osstest service owner
flight 184298 linux-5.4 real [real] flight 184304 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184298/ http://logs.test-lab.xenproject.org/osstest/logs/184304/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

Re: [PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Roger Pau Monné
On Wed, Jan 10, 2024 at 11:26:02AM +0100, Jan Beulich wrote: > On 10.01.2024 10:53, Roger Pau Monne wrote: > > The HVM pirq feature allows routing interrupts from both physical and > > emulated > > devices over event channels, this was done a performance improvement. > > However > > its usage is

Re: [PATCH v2 08/15] VMX: convert vmx_basic_msr

2024-01-10 Thread Jan Beulich
On 09.01.2024 15:54, Andrew Cooper wrote: > On 09/01/2024 2:39 pm, Jan Beulich wrote: >> Even the inner struct plan falls apart pretty quickly (or grows what >> needs doing by too much for my taste, in the context right here): >> While for basic_msr this works, and it would apparently also work >>

Re: [PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Jan Beulich
On 10.01.2024 10:53, Roger Pau Monne wrote: > The HVM pirq feature allows routing interrupts from both physical and emulated > devices over event channels, this was done a performance improvement. However > its usage is fully undocumented, and the only reference implementation is in > Linux. It d

Re: AMD EPYC VM to VM performance investigation

2024-01-10 Thread David Morel
On Thu, Jan 04, 2024 at 16:39:46PM, Stefano Stabellini wrote: > On Thu, 4 Jan 2024, David Morel wrote: > > Hello, > > > > We have a customer and multiple users on our forum having performances that > > seems quite low related to the general performance of the machines on AMD > > EPYC > > Zen host

Re: [PATCH v12 07/15] rangeset: add rangeset_purge() function

2024-01-10 Thread Jan Beulich
On 09.01.2024 22:51, Stewart Hildebrand wrote: > From: Volodymyr Babchuk > > This function can be used when user wants to remove all rangeset > entries but do not want to destroy rangeset itself. > > Signed-off-by: Volodymyr Babchuk > Signed-off-by: Stewart Hildebrand Acked-by: Jan Beulich

[PATCH] x86/hvm: don't expose XENFEAT_hvm_pirqs by default

2024-01-10 Thread Roger Pau Monne
The HVM pirq feature allows routing interrupts from both physical and emulated devices over event channels, this was done a performance improvement. However its usage is fully undocumented, and the only reference implementation is in Linux. It defeats the purpose of local APIC hardware virtualiza

Re: [PATCH v5 09/13] xen: add cache coloring allocator for domains

2024-01-10 Thread Jan Beulich
On 10.01.2024 01:46, Stefano Stabellini wrote: > On Tue, 9 Jan 2024, Jan Beulich wrote: >> On 02.01.2024 10:51, Carlo Nonato wrote: >>> This commit adds a new memory page allocator that implements the cache >>> coloring mechanism. The allocation algorithm enforces equal frequency >>> distribution o

Re: [PATCH v6 07/11] virtio-gpu: Handle resource blob commands

2024-01-10 Thread Pierre-Eric Pelloux-Prayer
Le 09/01/2024 à 17:50, Pierre-Eric Pelloux-Prayer a écrit : Le 19/12/2023 à 08:53, Huang Rui a écrit : From: Antonio Caggiano Support BLOB resources creation, mapping and unmapping by calling the new stable virglrenderer 0.10 interface. Only enabled when available and via the blob config.

Re: [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission

2024-01-10 Thread Chen, Jiqian
Thank Jan and Roger, I may know how to add a new hypercall XEN_DOMCTL_gsi_permission, I will implement it in next version. On 2024/1/9 18:46, Jan Beulich wrote: > On 09.01.2024 11:16, Chen, Jiqian wrote: >> On 2024/1/9 17:38, Jan Beulich wrote: >>> On 09.01.2024 09:18, Chen, Jiqian wrote: A

Re: [PATCH v2 4/7] xen/device-tree: Fix bootfdt.c to tolerate 0 reserved regions

2024-01-10 Thread Michal Orzel
On 09/01/2024 19:14, Julien Grall wrote: > > > (+ Stefano) > > Hi Shawn, > > On 15/12/2023 02:43, Shawn Anastasio wrote: >> The early_print_info routine in bootfdt.c incorrectly stores the result >> of a call to fdt_num_mem_rsv() in an unsigned int, which results in the >> negative error cod

[ovmf test] 184302: all pass - PUSHED

2024-01-10 Thread osstest service owner
flight 184302 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184302/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 265b4ab91b8a31d6d1760ad1eaa1e16f9244cba7 baseline version: ovmf edba0779ba05c0598dbdd

Re: [XEN RFC] x86/uaccess: remove __{put,get}_user_bad()

2024-01-10 Thread Federico Serafini
On 08/01/24 15:44, Jan Beulich wrote: On 08.01.2024 15:01, Federico Serafini wrote: Additionally, looking at violations of 16.3 on X86 [1], I think we should also consider generate_exception(), ASSERT_UNREACHABLE() and PARSE_ERR_RET() as allowed terminals for a switch-clause, do you agree? No,