Re: [PATCH] xen/smp: Speed up on_selected_cpus()

On 04.02.2022 21:31, Andrew Cooper wrote: > cpumask_weight() is a horribly expensive way to find if no bits are set, made > worse by the fact that the calculation is performed with the global call_lock > held. > > Switch to using cpumask_empty() instead, which will short circuit as soon as > it fi

Re: [PATCH] dom0/pvh: fix processing softirqs during memory map population

On 05.02.2022 11:18, Roger Pau Monne wrote: > Make sure softirqs are processed at least once for every call to > pvh_populate_memory_range. It's likely that none of the calls to > pvh_populate_memory_range will perform 64 iterations, in which case > softirqs won't be processed for the whole duratio

Re: [PATCH] x86/hvm: Fix boot on systems where HVM isn't available

On 05.02.2022 10:47, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 05:34:05PM +, Andrew Cooper wrote: >> c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to >> alt-call") went too far with dropping NULL function pointer checks. Oh, I'm sorry, I should have noticed th

Re: [PATCH RFC 0/3] xen/arm: Allow dom0 to use the EFI framebuffer

On 06.02.2022 20:28, Julien Grall wrote: > Looking through the dmesg, there are still a few TODOs to handle: > - Linux is not able to use the BGRT (Invalid address). This is > because the driver checks the Image address is part of the UEFI > Boot Services Area. Such area is not expo

Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP

On 06.02.2022 20:28, Julien Grall wrote: > From: Julien Grall > > Currently, the EFI stub will only query the console information and > get the GOP when using the configuration file. > > However, GRUB is never providing the a configuration file. So the > EFI framebuffer will not be usable at lea

Re: [PATCH] xen/x86: obtain full video frame buffer address for Dom0 also under EFI

On 07.02.22 08:41, Jan Beulich wrote: The initial change would not work when Xen was booted from EFI: There is an early exit from the case block in that case. Move the necessary code ahead of that. Fixes: 335e4dd67b48 ("xen/x86: obtain upper 32 bits of video frame buffer address for Dom0") Signe

Re: [PATCH RFC 2/3] xen/arm: efi: Introduce and fill the vga_console_info

On 06.02.2022 20:28, Julien Grall wrote: > From: Julien Grall > > In a follow-up patch will we want to add support for EFI framebuffer > in dom0. Yet, Xen may not use the framebuffer, so it would be ideal > to not have to enable CONFIG_VIDEO/CONFIG_VGA. > > Introduce vga_console_info in a hacky

Re: [PATCH RFC 3/3] xen: Introduce a platform sub-op to retrieve the VGA information

On 06.02.2022 20:28, Julien Grall wrote: > From: Julien Grall > > When using EFI, the VGA information is fetched using the EFI > boot services. However, Xen will have exited the boot services. > Therefore, we need to find a different way to pass the information > to dom0. > > For PV dom0, they a

Re: [PATCH 2/2] xen/x86: detect support for extended destination ID

On 20.01.22 16:25, Roger Pau Monne wrote: Xen allows the usage of some previously reserved bits in the IO-APIC RTE and the MSI address fields in order to store high bits for the target APIC ID. Such feature is already implemented by QEMU/KVM and HyperV, so in order to enable it just add the handl

Re: [PATCH 01/16] x86/P2M: rename p2m_remove_page()

On 04.02.2022 22:54, George Dunlap wrote: > On Mon, Jul 5, 2021 at 5:05 PM Jan Beulich wrote: > --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -788,8 +788,8 @@ void p2m_final_teardown(struct domain *d >> #ifdef CONFIG_HVM >> >> static int __must_check >> -p2m_remove_page(struct

Re: [PATCH 02/16] x86/P2M: introduce p2m_{add,remove}_page()

On 04.02.2022 23:07, George Dunlap wrote: > On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote: > >> p2m_add_page() is simply a rename from guest_physmap_add_entry(). >> p2m_remove_page() then is its counterpart, despite rendering >> guest_physmap_remove_page(). First of all: It has been long ago

Re: [PATCH 03/16] x86/P2M: drop a few CONFIG_HVM

On 04.02.2022 23:13, George Dunlap wrote: > On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote: > >> This is to make it easier to see which parts of p2m.c still aren't HVM- >> specific: In one case the conditionals sat in an already guarded region, >> while in the other case P2M_AUDIT implies HVM.

Re: [PATCH] dom0/pvh: fix processing softirqs during memory map population

On Mon, Feb 07, 2022 at 09:21:11AM +0100, Jan Beulich wrote: > On 05.02.2022 11:18, Roger Pau Monne wrote: > > Make sure softirqs are processed at least once for every call to > > pvh_populate_memory_range. It's likely that none of the calls to > > pvh_populate_memory_range will perform 64 iteratio

Re: [PATCH] dom0/pvh: fix processing softirqs during memory map population

On 07.02.2022 10:51, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 09:21:11AM +0100, Jan Beulich wrote: >> On 05.02.2022 11:18, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/hvm/dom0_build.c >>> +++ b/xen/arch/x86/hvm/dom0_build.c >>> @@ -186,7 +186,7 @@ static int __init pvh_populate_memory_ran

Re: [PATCH 08/16] x86/P2M: PoD, altp2m, and nested-p2m are HVM-only

On 05.02.2022 22:29, George Dunlap wrote: >> On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote: >> --- a/xen/arch/x86/mm/p2m-pod.c >> +++ b/xen/arch/x86/mm/p2m-pod.c >> @@ -1135,6 +1135,12 @@ p2m_pod_demand_populate(struct p2m_domai >> mfn_t mfn; >> unsigned long i; >> >> +if ( !p2m_is_hos

[PATCH] xen/x2apic: Fix inconsistent indenting

Eliminate the follow smatch warning: arch/x86/xen/enlighten_hvm.c:189 xen_cpu_dead_hvm() warn: inconsistent indenting. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- arch/x86/xen/enlighten_hvm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/xen/enlig

[PATCH] xen/public: partially revert commit 7c7f7e8fba01

Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible way. Unfortunately the changed parts were already in use in the Linux kernel, so an update of the header in the kernel would result in a build breakage. Even when removing its usage from the kernel the used flag bit should

[ovmf test] 168042: all pass - PUSHED

flight 168042 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168042/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f78b937c95ddc4f7a29e41fee98e96076828a108 baseline version: ovmf 6fb09da89f88000a75921

Re: [PATCH] xen/x2apic: Fix inconsistent indenting

On 07.02.22 11:35, Jiapeng Chong wrote: Eliminate the follow smatch warning: arch/x86/xen/enlighten_hvm.c:189 xen_cpu_dead_hvm() warn: inconsistent indenting. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Descrip

Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01

On 07.02.2022 11:36, Juergen Gross wrote: > Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible > way. Unfortunately the changed parts were already in use in the Linux > kernel, so an update of the header in the kernel would result in a build > breakage. > > Even when removi

Metadata and signalling channels for Zephyr virtio-backends on Xen

Hi Stefano, Vincent gave an update on his virtio-scmi work at the last Stratos sync call and the discussion moved onto next steps. Currently the demo setup is intermediated by a double-ended vhost-user daemon running on the devbox acting as a go between a number of QEMU instances representing th

Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01

On 07.02.22 11:46, Jan Beulich wrote: On 07.02.2022 11:36, Juergen Gross wrote: Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible way. Unfortunately the changed parts were already in use in the Linux kernel, so an update of the header in the kernel would result in a buil

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

Hello, On 04.02.22 16:57, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote: >> >> On 04.02.22 15:06, Roger Pau Monné wrote: >>> On Fri, Feb 04, 2022 at 12:53:20PM +, Oleksandr Andrushchenko wrote: On 04.02.22 14:47, Jan Beulich wrote: >

[PATCH v2] dom0/pvh: fix processing softirqs during memory map population

Make sure softirqs are processed after every successful call to guest_physmap_add_page. Even if only a single page is to be added, it's unknown whether the p2m or the IOMMU will require splitting the provided page into smaller ones, and thus in case of having to break a 1G page into 4K entries the

[xen-unstable test] 168037: tolerable FAIL

flight 168037 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168037/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-xsm 20 guest-start/debian.repeat fail pass in 168032 test-armhf-armhf-xl-rtds 18

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 09:29, Jan Beulich wrote: > On 04.02.2022 15:37, Oleksandr Andrushchenko wrote: >> On 04.02.22 16:30, Jan Beulich wrote: >>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: Reset the command register when assigning a PCI device to a guest: according to the PCI spec the P

Re: [PATCH RFC 3/3] xen: Introduce a platform sub-op to retrieve the VGA information

On Mon, Feb 07, 2022 at 09:57:55AM +0100, Jan Beulich wrote: > On 06.02.2022 20:28, Julien Grall wrote: > > From: Julien Grall > > > > When using EFI, the VGA information is fetched using the EFI > > boot services. However, Xen will have exited the boot services. > > Therefore, we need to find a

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 12:08, Oleksandr Andrushchenko wrote: > 1. vpci_{read|write} are not protected with pcidevs_lock and can run in > parallel with pci_remove_device which can remove pdev after vpci_{read|write} > acquired the pdev pointer. This may lead to a fail due to pdev dereference. > > So, to pro

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.2022 12:27, Oleksandr Andrushchenko wrote: > > > On 07.02.22 09:29, Jan Beulich wrote: >> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote: >>> On 04.02.22 16:30, Jan Beulich wrote: On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > Reset the command register when assigning

Re: [PATCH v2] dom0/pvh: fix processing softirqs during memory map population

On 07.02.2022 12:20, Roger Pau Monne wrote: > Make sure softirqs are processed after every successful call to > guest_physmap_add_page. Even if only a single page is to be added, > it's unknown whether the p2m or the IOMMU will require splitting the > provided page into smaller ones, and thus in ca

Re: [PATCH RFC 3/3] xen: Introduce a platform sub-op to retrieve the VGA information

On 07.02.2022 12:58, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 09:57:55AM +0100, Jan Beulich wrote: >> On 06.02.2022 20:28, Julien Grall wrote: >>> @@ -311,6 +312,7 @@ struct xenpf_firmware_info { >>> >>> /* Int16, Fn02: Get keyboard shift flags. */ >>> uint8_t kbd_shift_

Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01

On 07.02.2022 12:00, Juergen Gross wrote: > On 07.02.22 11:46, Jan Beulich wrote: >> On 07.02.2022 11:36, Juergen Gross wrote: >>> --- a/xen/include/public/memory.h >>> +++ b/xen/include/public/memory.h >>> @@ -662,7 +662,17 @@ struct xen_mem_acquire_resource { >>>* two calls. >>>*/

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote: > Hello, > > On 04.02.22 16:57, Roger Pau Monné wrote: > > On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote: > >> > >> On 04.02.22 15:06, Roger Pau Monné wrote: > >>> On Fri, Feb 04, 2022 at 12:53:20PM

Re: [PATCH v2] dom0/pvh: fix processing softirqs during memory map population

On Mon, Feb 07, 2022 at 01:41:38PM +0100, Jan Beulich wrote: > On 07.02.2022 12:20, Roger Pau Monne wrote: > > Make sure softirqs are processed after every successful call to > > guest_physmap_add_page. Even if only a single page is to be added, > > it's unknown whether the p2m or the IOMMU will re

Re: [PATCH] xen/public: partially revert commit 7c7f7e8fba01

On 07.02.22 13:46, Jan Beulich wrote: On 07.02.2022 12:00, Juergen Gross wrote: On 07.02.22 11:46, Jan Beulich wrote: On 07.02.2022 11:36, Juergen Gross wrote: --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -662,7 +662,17 @@ struct xen_mem_acquire_resource { * t

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 14:38, Jan Beulich wrote: > On 07.02.2022 12:27, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 09:29, Jan Beulich wrote: >>> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote: On 04.02.22 16:30, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.2022 13:51, Oleksandr Andrushchenko wrote: > > > On 07.02.22 14:38, Jan Beulich wrote: >> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote: >>> >>> On 07.02.22 09:29, Jan Beulich wrote: On 04.02.2022 15:37, Oleksandr Andrushchenko wrote: > On 04.02.22 16:30, Jan Beulich wrote:

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 14:34, Jan Beulich wrote: > On 07.02.2022 12:08, Oleksandr Andrushchenko wrote: >> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in >> parallel with pci_remove_device which can remove pdev after vpci_{read|write} >> acquired the pdev pointer. This may lead to a

[xtf test] 168044: all pass - PUSHED

flight 168044 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168044/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf bc0abf2a5498d4691538bf34496ca0f0f189951b baseline version: xtf 61e6f40b07d256bd62ae7b

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 13:57, Oleksandr Andrushchenko wrote: > > > On 07.02.22 14:34, Jan Beulich wrote: >> On 07.02.2022 12:08, Oleksandr Andrushchenko wrote: >>> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in >>> parallel with pci_remove_device which can remove pdev after >>> v

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 14:46, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote: >> Hello, >> >> On 04.02.22 16:57, Roger Pau Monné wrote: >>> On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote: On 04.02.22 15:06, Roger Pau Monné wrote

[ovmf test] 168043: all pass - PUSHED

flight 168043 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168043/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 96b8b5fd108a1f27960eee3915c0b10db191c849 baseline version: ovmf f78b937c95ddc4f7a29e4

[linux-linus test] 168041: tolerable FAIL - PUSHED

flight 168041 linux-linus real [real] flight 168045 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168041/ http://logs.test-lab.xenproject.org/osstest/logs/168045/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: > On 07.02.22 14:46, Roger Pau Monné wrote: >> I think the per-domain rwlock seems like a good option. I would do >> that as a pre-patch. > It is. But it seems it won't solve the thing we started this adventure for: > > With per-domain read lock

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 14:54, Jan Beulich wrote: > On 07.02.2022 13:51, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 14:38, Jan Beulich wrote: >>> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote: On 07.02.22 09:29, Jan Beulich wrote: > On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Mon, Feb 07, 2022 at 01:53:34PM +, Oleksandr Andrushchenko wrote: > > > On 07.02.22 14:46, Roger Pau Monné wrote: > > On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote: > >> == > >> > >> Bottom line: > >> ===

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: > On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: > > On 07.02.22 14:46, Roger Pau Monné wrote: > >> I think the per-domain rwlock seems like a good option. I would do > >> that as a pre-patch. > > It is. But it seems it won't solve t

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 16:19, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 01:53:34PM +, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 14:46, Roger Pau Monné wrote: >>> On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote: == B

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 16:11, Jan Beulich wrote: > On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: >> On 07.02.22 14:46, Roger Pau Monné wrote: >>> I think the per-domain rwlock seems like a good option. I would do >>> that as a pre-patch. >> It is. But it seems it won't solve the thing we started this

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.2022 15:17, Oleksandr Andrushchenko wrote: > > > On 07.02.22 14:54, Jan Beulich wrote: >> On 07.02.2022 13:51, Oleksandr Andrushchenko wrote: >>> >>> On 07.02.22 14:38, Jan Beulich wrote: On 07.02.2022 12:27, Oleksandr Andrushchenko wrote: > On 07.02.22 09:29, Jan Beulich wrote:

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 15:27, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: >> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: >>> On 07.02.22 14:46, Roger Pau Monné wrote: I think the per-domain rwlock seems like a good option. I would do that as a pre-

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 16:27, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: >> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: >>> On 07.02.22 14:46, Roger Pau Monné wrote: I think the per-domain rwlock seems like a good option. I would do that as a pre-

Re: [PATCH 08/16] x86/P2M: PoD, altp2m, and nested-p2m are HVM-only

> On Feb 7, 2022, at 10:11 AM, Jan Beulich wrote: > > On 05.02.2022 22:29, George Dunlap wrote: >>> On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote: >>> --- a/xen/arch/x86/mm/p2m-pod.c >>> +++ b/xen/arch/x86/mm/p2m-pod.c >>> @@ -1135,6 +1135,12 @@ p2m_pod_demand_populate(struct p2m_domai >>>

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 16:31, Jan Beulich wrote: > On 07.02.2022 15:17, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 14:54, Jan Beulich wrote: >>> On 07.02.2022 13:51, Oleksandr Andrushchenko wrote: On 07.02.22 14:38, Jan Beulich wrote: > On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.2022 15:46, Oleksandr Andrushchenko wrote: > On 07.02.22 16:31, Jan Beulich wrote: >> But: What's still missing here then is the separation of guest and host >> views. When we set INTx behind the guest's back, it shouldn't observe the >> bit set. Or is this meant to be another (big) TODO?

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 16:35, Oleksandr Andrushchenko wrote: > > On 07.02.22 16:27, Roger Pau Monné wrote: >> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: >>> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: On 07.02.22 14:46, Roger Pau Monné wrote: > I think the per-domain rwloc

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 17:05, Jan Beulich wrote: > On 07.02.2022 15:46, Oleksandr Andrushchenko wrote: >> On 07.02.22 16:31, Jan Beulich wrote: >>> But: What's still missing here then is the separation of guest and host >>> views. When we set INTx behind the guest's back, it shouldn't observe the >>> bit se

Re: [PATCH 08/16] x86/P2M: PoD, altp2m, and nested-p2m are HVM-only

On 07.02.2022 15:45, George Dunlap wrote: >> On Feb 7, 2022, at 10:11 AM, Jan Beulich wrote: >> On 05.02.2022 22:29, George Dunlap wrote: On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote: --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -1135,6 +1135,12 @@ p2m_p

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 16:11, Oleksandr Andrushchenko wrote: > > > On 07.02.22 16:35, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 16:27, Roger Pau Monné wrote: >>> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: On 07.02.2022 14:53, Oleksandr Andrushchenko wrote: > On 07.02.22 1

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.2022 16:14, Oleksandr Andrushchenko wrote: > On 07.02.22 17:05, Jan Beulich wrote: >> On 07.02.2022 15:46, Oleksandr Andrushchenko wrote: >>> On 07.02.22 16:31, Jan Beulich wrote: But: What's still missing here then is the separation of guest and host views. When we set INTx behi

Re: [PATCH 02/16] x86/P2M: introduce p2m_{add,remove}_page()

> On Feb 7, 2022, at 9:38 AM, Jan Beulich wrote: > > On 04.02.2022 23:07, George Dunlap wrote: >> On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote: >> >>> p2m_add_page() is simply a rename from guest_physmap_add_entry(). >>> p2m_remove_page() then is its counterpart, despite rendering >>> gue

[ovmf test] 168046: all pass - PUSHED

flight 168046 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168046/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1f54eaa725f45e0c66c28f8d47fa8fb33f7be52c baseline version: ovmf 96b8b5fd108a1f27960ee

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 07.02.22 17:28, Jan Beulich wrote: > On 07.02.2022 16:14, Oleksandr Andrushchenko wrote: >> On 07.02.22 17:05, Jan Beulich wrote: >>> On 07.02.2022 15:46, Oleksandr Andrushchenko wrote: On 07.02.22 16:31, Jan Beulich wrote: > But: What's still missing here then is the separation of gu

Re: [PATCH] x86/hvm: Fix boot on systems where HVM isn't available

On 07/02/2022 08:29, Jan Beulich wrote: > On 05.02.2022 10:47, Roger Pau Monné wrote: >> On Fri, Feb 04, 2022 at 05:34:05PM +, Andrew Cooper wrote: >>> c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to >>> alt-call") went too far with dropping NULL function pointer che

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 17:26, Jan Beulich wrote: > On 07.02.2022 16:11, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 16:35, Oleksandr Andrushchenko wrote: >>> On 07.02.22 16:27, Roger Pau Monné wrote: On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: > On 07.02.2022 14:53, Oleksandr

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Mon, Feb 07, 2022 at 04:26:56PM +0100, Jan Beulich wrote: > On 07.02.2022 16:11, Oleksandr Andrushchenko wrote: > > > > > > On 07.02.22 16:35, Oleksandr Andrushchenko wrote: > >> > >> On 07.02.22 16:27, Roger Pau Monné wrote: > >>> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote: >

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 17:08, Roger Pau Monné wrote: > On Mon, Feb 07, 2022 at 04:26:56PM +0100, Jan Beulich wrote: >> On 07.02.2022 16:11, Oleksandr Andrushchenko wrote: >>> >>> >>> On 07.02.22 16:35, Oleksandr Andrushchenko wrote: On 07.02.22 16:27, Roger Pau Monné wrote: > On Mon, Feb 07, 2

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 17:07, Oleksandr Andrushchenko wrote: > On 07.02.22 17:26, Jan Beulich wrote: >> 1b. Make vpci_write use write lock for writes to command register and BARs >> only; keep using the read lock for all other writes. > I am not quite sure how to do that. Do you mean something like: > void

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 18:15, Jan Beulich wrote: > On 07.02.2022 17:07, Oleksandr Andrushchenko wrote: >> On 07.02.22 17:26, Jan Beulich wrote: >>> 1b. Make vpci_write use write lock for writes to command register and BARs >>> only; keep using the read lock for all other writes. >> I am not quite sure how t

Re: [PATCH v6 05/13] vpci: add hooks for PCI device assign/de-assign

On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > @@ -1507,6 +1511,8 @@ static int assign_device(struct domain *d, u16 seg, u8 > bus, u8 devfn, u32 flag) > pci_to_dev(pdev), flag); > } > > +rc = vpci_assign_device(d, pdev); > + > done: > if ( rc ) >

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.2022 17:21, Oleksandr Andrushchenko wrote: > > > On 07.02.22 18:15, Jan Beulich wrote: >> On 07.02.2022 17:07, Oleksandr Andrushchenko wrote: >>> On 07.02.22 17:26, Jan Beulich wrote: 1b. Make vpci_write use write lock for writes to command register and BARs only; keep using th

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 07.02.22 18:37, Jan Beulich wrote: > On 07.02.2022 17:21, Oleksandr Andrushchenko wrote: >> >> On 07.02.22 18:15, Jan Beulich wrote: >>> On 07.02.2022 17:07, Oleksandr Andrushchenko wrote: On 07.02.22 17:26, Jan Beulich wrote: > 1b. Make vpci_write use write lock for writes to command

Re: [XEN PATCH v3] xen/arm: introduce dummy iommu node for dom0

Hi, On 11/01/2022 11:26, Sergiy Kibrik wrote: Currently no IOMMU properties are exposed to dom0, thus kernel by default assumes no protection and enables swiotlb-xen, which leads to costly and unnecessary buffers bouncing. To let kernel know which device is behing IOMMU and hence needs no swiot

Re: [PATCH v6 06/13] vpci/header: implement guest BAR register handlers

On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > +static uint32_t guest_bar_ignore_read(const struct pci_dev *pdev, > + unsigned int reg, void *data) > +{ > +return 0; > +} > + > +static int bar_ignore_access(const struct pci_dev *pdev, unsigned int reg

Re: [PATCH] xen/smp: Speed up on_selected_cpus()

On 07/02/2022 08:11, Jan Beulich wrote: > On 04.02.2022 21:31, Andrew Cooper wrote: >> cpumask_weight() is a horribly expensive way to find if no bits are set, made >> worse by the fact that the calculation is performed with the global call_lock >> held. >> >> Switch to using cpumask_empty() instea

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

Hi Oleksandr, On 05/01/2022 23:11, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Rework Arm implementation to store grant table frame GFN in struct page_info directly instead of keeping it in standalone status/shared arrays. This patch is based on the assumption that grant table page

Re: [PATCH] xen/smp: Speed up on_selected_cpus()

On 06/02/2022 19:40, Julien Grall wrote: > Hi, > > On 04/02/2022 20:31, Andrew Cooper wrote: >> cpumask_weight() is a horribly expensive way to find if no bits are >> set, made >> worse by the fact that the calculation is performed with the global >> call_lock >> held. > > I looked at the archive b

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

Hi, Sorry for the late reply. On 06/01/2022 16:30, Oleksandr wrote: So I agree with Jan that the name should be adjusted if it stays where it is. That said, I would actually prefer the adjustment in alloc_heap_pages(). It is one less assignment per page and I don't expect any issue with se

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

On 07/02/2022 17:58, Oleksandr Tyshchenko wrote: On 07.02.22 19:41, Julien Grall wrote: On 06/01/2022 16:30, Oleksandr wrote: So I agree with Jan that the name should be adjusted if it stays where it is. That said, I would actually prefer the adjustment in alloc_heap_pages(). It is one les

Re: [PATCH v2 0/5] tools: remove include/xen-external directory

On Mon, Feb 07, 2022 at 07:41:42AM +0100, Juergen Gross wrote: > The tools/include/xen-external directory contains a header file from > FreeBSD used to generate Xen header files. This series is replacing the > complete directory by a single header with the same semantics. > > Changes in V2: > - re

[PATCH v2 0/2] xen: Report and use hardware APIC virtualization capabilities

Jane Malalane (2): xen+tools: Report Interrupt Controller Virtualization capabilities on x86 x86/xen: Allow per-domain usage of hardware virtualized APIC docs/man/xl.cfg.5.pod.in | 10 + docs/man/xl.conf.5.pod.in | 12 ++ tools/golang/xenlight/help

[PATCH v2 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86

Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic and x2apic, on x86 hardware. No such features are currently implemented on AMD hardware. For that purpose, also add an arch-specific "capabilities" parameter to struct xen_sysctl_phys

[PATCH v2 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

Introduce a new per-domain creation x86 specific flag to select whether hardware assisted virtualization should be used for x{2}APIC. A per-domain option is added to xl in order to select the usage of x{2}APIC hardware assisted vitualization, as well as a global configuration option. Having all A

Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP

Hi Jan, On 07/02/2022 08:46, Jan Beulich wrote: On 06.02.2022 20:28, Julien Grall wrote: From: Julien Grall Currently, the EFI stub will only query the console information and get the GOP when using the configuration file. However, GRUB is never providing the a configuration file. So the EFI

Re: [PATCH RFC 2/3] xen/arm: efi: Introduce and fill the vga_console_info

Hi, On 07/02/2022 08:53, Jan Beulich wrote: On 06.02.2022 20:28, Julien Grall wrote: From: Julien Grall In a follow-up patch will we want to add support for EFI framebuffer in dom0. Yet, Xen may not use the framebuffer, so it would be ideal to not have to enable CONFIG_VIDEO/CONFIG_VGA. Intr

Re: [PATCH RFC 3/3] xen: Introduce a platform sub-op to retrieve the VGA information

Hi Roger, On 07/02/2022 11:58, Roger Pau Monné wrote: On Mon, Feb 07, 2022 at 09:57:55AM +0100, Jan Beulich wrote: On 06.02.2022 20:28, Julien Grall wrote: From: Julien Grall When using EFI, the VGA information is fetched using the EFI boot services. However, Xen will have exited the boot se

[ovmf test] 168048: all pass - PUSHED

flight 168048 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/168048/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b360b0b589697da267f5d3a553e65635b91ebae2 baseline version: ovmf 1f54eaa725f45e0c66c28

[xen-unstable-smoke test] 168049: tolerable all pass - PUSHED

flight 168049 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168049/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

[qemu-mainline test] 168047: tolerable FAIL - PUSHED

flight 168047 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168047/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168034 test-amd64-amd64-xl-qemuu-win7-amd6

Re: Metadata and signalling channels for Zephyr virtio-backends on Xen

On Mon, 7 Feb 2022, Alex Bennée wrote: > Hi Stefano, > > Vincent gave an update on his virtio-scmi work at the last Stratos sync > call and the discussion moved onto next steps. Hi Alex, I don't know the specifics of virtio-scmi, but if it is about power, clocks, reset, etc. like the original SC

Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device

On Fri, 4 Feb 2022, Rob Herring wrote: > On Wed, Jan 26, 2022 at 10:56:39AM -0800, Stefano Stabellini wrote: > > On Wed, 26 Jan 2022, Robin Murphy wrote: > > > On 2022-01-26 15:09, Sergiy Kibrik wrote: > > > > Hi Robin, > > > > > > > > > > > > > > This could break Linux guests, since depending on

[linux-linus test] 168050: tolerable FAIL - PUSHED

flight 168050 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/168050/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168041 test-amd64-amd64-qemuu-nested-amd 20

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

On 07.02.22 19:59, Julien Grall wrote: Hi Julien > > > On 07/02/2022 17:58, Oleksandr Tyshchenko wrote: >> >> On 07.02.22 19:41, Julien Grall wrote: >>> On 06/01/2022 16:30, Oleksandr wrote: >>> >>> So I agree with Jan that the name should be adjusted if it stays where >>> it is. >>> >>> That s

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

On 07.02.22 19:41, Julien Grall wrote: > Hi, Hi Julien > > Sorry for the late reply. np > > On 06/01/2022 16:30, Oleksandr wrote: > > So I agree with Jan that the name should be adjusted if it stays where > it is. > > That said, I would actually prefer the adjustment in > alloc_heap_pages

Re: [PATCH V5] xen/gnttab: Store frame GFN in struct page_info on Arm

On 07.02.22 19:15, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > > On 05/01/2022 23:11, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko >> >> Rework Arm implementation to store grant table frame GFN >> in struct page_info directly instead of keeping it in >> standalone status/sh

Re: [PATCH v2 0/5] tools: remove include/xen-external directory

On 07.02.22 19:09, Anthony PERARD wrote: On Mon, Feb 07, 2022 at 07:41:42AM +0100, Juergen Gross wrote: The tools/include/xen-external directory contains a header file from FreeBSD used to generate Xen header files. This series is replacing the complete directory by a single header with the same

[PATCH v3 0/5] tools: remove include/xen-external directory

The tools/include/xen-external directory contains a header file from FreeBSD used to generate Xen header files. This series is replacing the complete directory by a single header with the same semantics. Changes in V3: - fix patch 3 Changes in V2: - remove stale comment in patch 1 Juergen Gross

[PATCH v3 4/5] tools/libs/evtchn: use _xen_list.h

Instead of including xen-external/bsd-sys-queue.h use the header _xen_list.h in minios.c. Signed-off-by: Juergen Gross --- tools/libs/evtchn/minios.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c

[PATCH v3 1/5] tools/include: generate a _xen_list.h file

Today tools/include contains two basically identical header files generated from the same source. They just differ by the used name space and they are being generated from different Makefiles via a perl script. Prepare to have only one such header by using a more generic namespace "XEN" for _xen_l

[PATCH v3 2/5] tools/libs/light: replace _libxl_list.h with _xen_list.h

Remove generating _libxl_list.h and use the common _xen_list.h instead. Signed-off-by: Juergen Gross --- tools/include/libxl.h| 4 +- tools/libs/light/Makefile| 10 +-- tools/libs/light/libxl.c | 40 - tools/libs/light/libxl_aoutils.c | 20

  1   2   >