[Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

As multiple rather important patch series are very short before being ready I have decided to push the hard code freeze one week back to October 4th. This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.13 so that people have an idea what is going

Re: [Xen-devel] Latest development (master) Xen fails to boot on HP ProLiant DL20 GEN10

On Thu, Sep 26, 2019 at 12:44 AM Jan Beulich wrote: > > On 26.09.2019 00:31, Roman Shaposhnik wrote: > > Jan, Roger, thank you so much for the initial ideas. I tried a few of > > those and here's where I am. > > > > First of all, it is definitely related to CPU bring up. Adding > > cpuidle=0 to

[Xen-devel] [qemu-mainline test] 141886: regressions - FAIL

flight 141886 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141886/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282

[Xen-devel] [libvirt test] 141893: tolerable FAIL - PUSHED

flight 141893 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141893/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail like 141859 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [PATCH V6 0/8] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec

Hi Stefano Sorry for the possible format issues. сб, 28 сент. 2019 г., 01:50 Stefano Stabellini : > On Thu, 26 Sep 2019, Oleksandr wrote: > > On 26.09.19 17:56, Julien Grall wrote: > > > Hi, > > > > Hi Julien > > > > > > > > > > On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote: > > > >

Re: [Xen-devel] [PATCH v5 5/8] xen/arm: assign devices to boot domains

On Fri, 27 Sep 2019, Julien Grall wrote: > Hi, > > On 27/09/2019 15:40, Oleksandr wrote: > > > > On 26.09.19 00:12, Julien Grall wrote: > >> On 25/09/2019 19:49, Stefano Stabellini wrote: > >>> Scan the user provided dtb fragment at boot. For each device node, map > >>> memory to guests, and

[Xen-devel] [freebsd-master test] 141895: regressions - trouble: blocked/fail

flight 141895 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/141895/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501 Tests which did

Re: [Xen-devel] [PATCH V6 0/8] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec

On Thu, 26 Sep 2019, Oleksandr wrote: > On 26.09.19 17:56, Julien Grall wrote: > > Hi, > > Hi Julien > > > > > > On 9/26/19 12:20 PM, Oleksandr Tyshchenko wrote: > > > Oleksandr Tyshchenko (8): > > >    iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff > > >    iommu/arm: Add

[Xen-devel] [xen-unstable test] 141882: regressions - FAIL

flight 141882 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141882/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 141822

Re: [Xen-devel] [PATCH RESEND v1 1/8] stubdom/vtpm: include stdio.h for declaration of printf

On 9/24/19 10:03 AM, Olaf Hering wrote: The function read_vtpmblk uses printf(3), but stdio.h is not included in this file. This results in a warning from gcc-7: vtpmblk.c: In function 'read_vtpmblk': vtpmblk.c:322:7: warning: implicit declaration of function 'printf'

Re: [Xen-devel] [PATCH v5 5/8] xen/arm: assign devices to boot domains (fwd)

Hi Juergen, This email is about the dom0less device assignment patch series. It is very close to ready. I sent v6 yesterday addressing the remaining comments from Julien. We are down to smaller details. Oleksandr's iommu series got merged today. That requires a small changes to the patch below.

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Hi, On 27/09/2019 18:58, Volodymyr Babchuk wrote: > > Julien Grall writes: > >> Hi, >> >> On 27/09/2019 15:21, Volodymyr Babchuk wrote: >>> >>> Julien Grall writes: >>> On 27/09/2019 14:33, Volodymyr Babchuk wrote: > Julien Grall writes: >> On 27/09/2019 13:39, Volodymyr Babchuk

[Xen-devel] [xen-unstable-smoke test] 141909: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH v5 5/8] xen/arm: assign devices to boot domains

Hi, On 27/09/2019 15:40, Oleksandr wrote: > > On 26.09.19 00:12, Julien Grall wrote: >> On 25/09/2019 19:49, Stefano Stabellini wrote: >>> Scan the user provided dtb fragment at boot. For each device node, map >>> memory to guests, and route interrupts and setup the iommu. >>> >>> The memory

Re: [Xen-devel] [PATCH v1] xen/balloon: Set pages PageOffline() in balloon_add_region()

On 9/27/19 11:46 AM, David Hildenbrand wrote: > We are missing a __SetPageOffline(), which is why we can get > !PageOffline() pages onto the balloon list, where > alloc_xenballooned_pages() will complain: > > page:ea0003e7ffc0 refcount:1 mapcount:0 mapping: index:0x0 > flags:

[Xen-devel] [linux-4.19 test] 141878: regressions - FAIL

flight 141878 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141878/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which are

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Julien Grall writes: > Hi, > > On 27/09/2019 15:21, Volodymyr Babchuk wrote: >> >> Julien Grall writes: >> >>> On 27/09/2019 14:33, Volodymyr Babchuk wrote: Julien Grall writes: > On 27/09/2019 13:39, Volodymyr Babchuk wrote: >> Julien Grall writes: >>> On 27/09/2019 12:56,

[Xen-devel] [linux-linus test] 141870: regressions - FAIL

flight 141870 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141870/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580

Re: [Xen-devel] [PATCH v1] libxl: fix crash in helper_done due to uninitialized data

Olaf Hering writes ("[PATCH v1] libxl: fix crash in helper_done due to uninitialized data"): > A crash in helper_done, called from libxl_domain_suspend, was reported, > triggered by 'virsh migrate --live xen+ssh://host': ... > This is triggered by a failed poll, the actual error was: > >

Re: [Xen-devel] [PATCH v4 00/46] xen: add core scheduling support

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > Add support for core- and socket-scheduling in the Xen hypervisor. > Ok, I think I've reviewed all the patches. They all should have the appropriate tag for going in (unless I've missed any) except patch 35, for which I've asked more

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Hi, On 27/09/2019 15:21, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 14:33, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 13:39, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 12:56, Volodymyr Babchuk wrote: Julien Grall writes: Or maybe, we

Re: [Xen-devel] [PATCH v4 44/46] xen/sched: support core scheduling for moving cpus to/from cpupools

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > With core scheduling active it is necessary to move multiple cpus at > the same time to or from a cpupool in order to avoid split scheduling > resources in between. > > Signed-off-by: Juergen Gross > Reviewed-by: Dario Faggioli Regards

[Xen-devel] [PATCH v1] libxl: fix crash in helper_done due to uninitialized data

A crash in helper_done, called from libxl_domain_suspend, was reported, triggered by 'virsh migrate --live xen+ssh://host': #1 helper_done (...) at libxl_save_callout.c:371 helper_failed helper_stop libxl__save_helper_abort #2 check_all_finished (..., rc=-3) at libxl_stream_write.c:671

Re: [Xen-devel] [PATCH v4 43/46] xen/sched: support differing granularity in schedule_cpu_[add/rm]()

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > With core scheduling active schedule_cpu_[add/rm]() has to cope with > different scheduling granularity: a cpu not in any cpupool is subject > to granularity 1 (cpu scheduling), while a cpu in a cpupool might be > in a scheduling resource

[Xen-devel] [xen-unstable-smoke test] 141902: tolerable all pass - PUSHED

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

[Xen-devel] [PATCH v12] microcode: rendezvous CPUs in NMI handler and load ucode

When one core is loading ucode, handling NMI on sibling threads or on other cores in the system might be problematic. By rendezvousing all CPUs in NMI handler, it prevents NMI acceptance during ucode loading. Basically, some work previously done in stop_machine context is moved to NMI handler.

Re: [Xen-devel] [PATCH v4 42/46] xen/sched: support multiple cpus per scheduling resource

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > Prepare supporting multiple cpus per scheduling resource by > allocating > the cpumask per resource dynamically. > > Modify sched_res_mask to have only one bit per scheduling resource > set. > > Signed-off-by: Juergen Gross >

[Xen-devel] [PATCH] xen/efi: Set nonblocking callbacks

Other parts of the kernel expect these nonblocking EFI callbacks to exist and crash when running under Xen. Since the implementations of xen_efi_set_variable() and xen_efi_query_variable_info() do not take any locks, use them for the nonblocking callbacks too. Signed-off-by: Ross Lagerwall ---

[Xen-devel] [PATCH v1] xen/balloon: Set pages PageOffline() in balloon_add_region()

We are missing a __SetPageOffline(), which is why we can get !PageOffline() pages onto the balloon list, where alloc_xenballooned_pages() will complain: page:ea0003e7ffc0 refcount:1 mapcount:0 mapping: index:0x0 flags: 0xe1000(reserved) raw: 000e1000

Re: [Xen-devel] [PATCH v4 41/46] xen/sched: protect scheduling resource via rcu

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > In order to be able to move cpus to cpupools with core scheduling > active it is mandatory to merge multiple cpus into one scheduling > resource or to split a scheduling resource with multiple cpus in it > into multiple scheduling

Re: [Xen-devel] [PATCH v4 40/46] xen/sched: split schedule_cpu_switch()

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > Instead of letting schedule_cpu_switch() handle moving cpus from and > to cpupools, split it into schedule_cpu_add() and schedule_cpu_rm(). > > This will allow us to drop allocating/freeing scheduler data for free > cpus as the idle

Re: [Xen-devel] [PATCH RFC for-4.13 08/10] xen/arm: alternative: add auto-nop infrastructure

Julien Grall writes: > From: Mark Rutland > > In some cases, one side of an alternative sequence is simply a number of > NOPs used to balance the other side. Keeping track of this manually is > tedious, and the presence of large chains of NOPs makes the code more > painful to read than

Re: [Xen-devel] VM_BUG_ON_PAGE(!PageOffline(page), page) in alloc_xenballooned_pages

On Fri, Sep 27, 2019 at 09:44:35AM +0200, David Hildenbrand wrote: > On 26.09.19 23:34, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I've hit VM_BUG_ON_PAGE(!PageOffline(page), page) in > > alloc_xenballooned_pages, when trying to use gnttab from userspace > > application. It happens on Xen

Re: [Xen-devel] [PATCH v4 39/46] xen/sched: prepare per-cpupool scheduling granularity

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > On- and offlining cpus with core scheduling is rather complicated as > the cpus are taken on- or offline one by one, but scheduling wants > them > rather to be handled per core. > > As the future plan is to be able to select scheduling

Re: [Xen-devel] [PATCH RFC for-4.13 10/10] xen/arm64: entry: Ensure the guest state is synced when receiving a vSError

Hi Julien, Julien Grall writes: > At the moment, when a SError is received while checking for a pending > one, we will skip the handling the initial exception. > > This includes call to exit_from_guest{, _noirq} that is used to Did you mean enter_hypervisor_from_guest{, _noirq} there?

Re: [Xen-devel] [PATCH v4 35/46] xen/sched: make vcpu_wake() and vcpu_sleep() core scheduling aware

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > vcpu_wake() and vcpu_sleep() need to be made core scheduling aware: > they might need to switch a single vcpu of an already scheduled unit > between running and not running. > > Especially when vcpu_sleep() for a vcpu is being called by a

Re: [Xen-devel] [PATCH v4 34/46] xen/sched: add fall back to idle vcpu when scheduling unit

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > When scheduling an unit with multiple vcpus there is no guarantee all > vcpus are available (e.g. above maxvcpus or vcpu offline). Fall back > to > idle vcpu of the current cpu in that case. This requires to store the > correct

[Xen-devel] [ovmf test] 141888: all pass - PUSHED

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

Re: [Xen-devel] [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support

Jürgen Groß writes ("Re: [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support"): > On 27.09.19 15:37, Ian Jackson wrote: > > I think this is ASCII printing characters with the exception of > >! " ` $ % ^ & * = + { } ' ~ < > / \ | > > > > I struggle to find a

Re: [Xen-devel] [PATCH v4 33/46] xen/sched: add a percpu resource index

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > Add a percpu variable holding the index of the cpu in the current > sched_resource structure. This index is used to get the correct vcpu > of a sched_unit on a specific cpu. > > For now this index will be zero for all cpus, but with core >

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 27/09/2019 15:14, Jan Beulich wrote: On 27.09.2019 16:02, hong...@amazon.com wrote: But then why do the initial so many patches (inherited from Wei) convert from domheap to xenheap allocations at all? If your approach is to be at least an intermediate goal, then I think the order of changes

Re: [Xen-devel] [PATCH v4 32/46] xen/sched: support allocating multiple vcpus into one sched unit

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > With a scheduling granularity greater than 1 multiple vcpus share the > same struct sched_unit. Support that. > > Setting the initial processor must be done carefully: we can't use > sched_set_res() as that relies on

Re: [Xen-devel] [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support

On 27.09.19 15:37, Ian Jackson wrote: Jürgen Groß writes ("Re: [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support"): On 27.09.19 12:37, Ian Jackson wrote: I guess that keys will be chosen from some limited safe character set ? What about values ? Might we create

Re: [Xen-devel] [PATCH] x86: correct bogus error indicator of cpu_add()

On 27.09.19 16:43, Jan Beulich wrote: Commit 54ce2db8b8 ("x86/numa: adjust datatypes for node and pxm") changed this from the -1 (i.e. -EPERM, which was already bogus) that comes back from setup_node() to NUMA_NO_NODE (0xff). Use a proper error indicator instead. Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v4 30/46] xen/sched: add support for multiple vcpus per sched unit where missing

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > In several places there is support for multiple vcpus per sched unit > missing. Add that missing support (with the exception of initial > allocation) and missing helpers for that. > > Signed-off-by: Juergen Gross > Reviewed-by: Dario

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 27/09/2019 15:14, Jan Beulich wrote: On 27.09.2019 16:02, hong...@amazon.com wrote: But then why do the initial so many patches (inherited from Wei) convert from domheap to xenheap allocations at all? If your approach is to be at least an intermediate goal, then I think the order of changes

Re: [Xen-devel] [PATCH] x86: correct bogus error indicator of cpu_add()

On 27/09/2019 15:43, Jan Beulich wrote: > Commit 54ce2db8b8 ("x86/numa: adjust datatypes for node and pxm") > changed this from the -1 (i.e. -EPERM, which was already bogus) that > comes back from setup_node() to NUMA_NO_NODE (0xff). Use a proper error > indicator instead. > > Signed-off-by: Jan

[Xen-devel] [PATCH] x86: correct bogus error indicator of cpu_add()

Commit 54ce2db8b8 ("x86/numa: adjust datatypes for node and pxm") changed this from the -1 (i.e. -EPERM, which was already bogus) that comes back from setup_node() to NUMA_NO_NODE (0xff). Use a proper error indicator instead. Signed-off-by: Jan Beulich --- a/xen/arch/x86/smpboot.c +++

Re: [Xen-devel] [PATCH v5 5/8] xen/arm: assign devices to boot domains

On 26.09.19 00:12, Julien Grall wrote: Hi Stefano, Hi Stefano, Julien On 25/09/2019 19:49, Stefano Stabellini wrote: Scan the user provided dtb fragment at boot. For each device node, map memory to guests, and route interrupts and setup the iommu. The memory region to remap is

Re: [Xen-devel] [PATCH v4 28/46] xen/sched: add code to sync scheduling of all vcpus of a sched unit

On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: > When switching sched units synchronize all vcpus of the new unit to > be > scheduled at the same time. > > A variable sched_granularity is added which holds the number of vcpus > per schedule unit. > > As tasklets require to schedule the

Re: [Xen-devel] [PATCH v7 0/4] Fix PCI passthrough for HVM with stubdomain

On Fri, Sep 27, 2019 at 04:21:55PM +0200, Jan Beulich wrote: > > > > Marek Marczykowski-Górecki (4): > > libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use > > libxl: attach PCI device to qemu only after setting pciback/pcifront > > libxl: don't try to manipulate json

Re: [Xen-devel] [PATCH v7 0/4] Fix PCI passthrough for HVM with stubdomain

Ian, Wei, On 25.09.2019 04:41, Marek Marczykowski-Górecki wrote: > In this version, I drop PHYSDEVOP_interrupt_control patch, since Jan prefer > not > to mix pciif and hypercalls for serving device model. Enabling MSI by the > stubdomain remains unsolved here, but other patches are improvement

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Julien Grall writes: > On 27/09/2019 14:33, Volodymyr Babchuk wrote: >> Julien Grall writes: >>> On 27/09/2019 13:39, Volodymyr Babchuk wrote: Julien Grall writes: > On 27/09/2019 12:56, Volodymyr Babchuk wrote: >> Julien Grall writes: >> >>> At the moment, SSBD workaround

Re: [Xen-devel] [PATCH v2 5/6] Add guide on Communication Best Practice

On 27.09.2019 12:17, Lars Kurth wrote: > Can I maybe get you to reconsider and re-review the next version from the > view point of an author and maybe make suggestions on how to create more > balance I'll certainly make an attempt. Jan ___ Xen-devel

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 27.09.2019 16:02, hong...@amazon.com wrote: > On 27/09/2019 14:00, Jan Beulich wrote: >> On 27.09.2019 14:54, hong...@amazon.com wrote: >> >> Pre-populate? There's some conceptional question then: When the >> direct map is gone, are you mapping Xen heap pages into the place >> they'd have lived

Re: [Xen-devel] [PATCH v11 6/7] microcode: rendezvous CPUs in NMI handler and load ucode

On Fri, Sep 27, 2019 at 03:55:00PM +0200, Jan Beulich wrote: >On 27.09.2019 15:53, Chao Gao wrote: >> On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote: >>> On 26.09.2019 15:53, Chao Gao wrote: @@ -420,14 +498,23 @@ static int control_thread_fn(const struct microcode_patch

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

On 27/09/2019 14:33, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 13:39, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 12:56, Volodymyr Babchuk wrote: Julien Grall writes: At the moment, SSBD workaround is re-enabled for Xen after interrupts are unmasked.

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 27/09/2019 14:00, Jan Beulich wrote: On 27.09.2019 14:54, hong...@amazon.com wrote: Pre-populate? There's some conceptional question then: When the direct map is gone, are you mapping Xen heap pages into the place they'd have lived at in the direct map? I'm not convinced that's what we want.

[Xen-devel] [ANNOUNCE] Call for agenda items for Oct, 10th Community Call @ 15:00 UTC - One week later than normal

Hi all, the proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/4FGEw81flPUiivkjkuvQJ-CK/embed/present/and you can edit to add items Alternatively, you can reply to this mail directly Agenda items appreciated a few days before the call: please put your name besides items if you edit

Re: [Xen-devel] [PATCH v11 6/7] microcode: rendezvous CPUs in NMI handler and load ucode

On 27.09.2019 15:53, Chao Gao wrote: > On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote: >> On 26.09.2019 15:53, Chao Gao wrote: >>> @@ -420,14 +498,23 @@ static int control_thread_fn(const struct >>> microcode_patch *patch) >>> return ret; >>> } >>> >>> -/* Let

Re: [Xen-devel] [win-pv-devel] [Vote] XCP-ng subproject proposal

+1 from me On Fri, 27 Sep 2019 at 14:00, Lars Kurth wrote: > > > > On 9 Sep 2019, at 15:44, Lars Kurth wrote: > > Hello everyone, > > Olivier had posted an RFC for this proposal on xen-devel@- see > https://xen.markmail.org/thread/ermnrb3ps3okvnjr > > The proposal also has been discussed by

Re: [Xen-devel] [PATCH v11 6/7] microcode: rendezvous CPUs in NMI handler and load ucode

On Fri, Sep 27, 2019 at 12:19:22PM +0200, Jan Beulich wrote: >On 26.09.2019 15:53, Chao Gao wrote: >> @@ -105,23 +110,42 @@ void __init microcode_set_module(unsigned int idx) >> } >> >> /* >> - * The format is '[|scan]'. Both options are optional. >> + * The format is '[|scan, nmi=]'. Both

Re: [Xen-devel] [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support

Jürgen Groß writes ("Re: [PATCH v1 1/6] docs: add feature document for Xen hypervisor sysfs-like support"): > On 27.09.19 12:37, Ian Jackson wrote: > > I guess that keys will be chosen from some limited safe character > > set ? What about values ? Might we create a key whose value contains > >

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Hi, Julien Grall writes: > Hi, > > On 27/09/2019 13:39, Volodymyr Babchuk wrote: >> Julien Grall writes: >>> On 27/09/2019 12:56, Volodymyr Babchuk wrote: Julien Grall writes: > At the moment, SSBD workaround is re-enabled for Xen after interrupts > are unmasked. This means we

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Hi, On 27/09/2019 13:39, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 12:56, Volodymyr Babchuk wrote: Julien Grall writes: At the moment, SSBD workaround is re-enabled for Xen after interrupts are unmasked. This means we may end up to execute some part of the hypervisor if an

Re: [Xen-devel] [RFC PATCH 58/84] x86/mm: fix leaks in map_xen_pagetable.

On 26/09/2019 14:16, Wei Liu wrote: On Thu, Sep 26, 2019 at 10:46:21AM +0100, hong...@amazon.com wrote: diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index b2b2edbed1..145c5ab47c 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5160,6 +5160,7 @@ int map_pages_to_xen(

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

Hi, On 27/09/2019 13:54, hong...@amazon.com wrote: On 26/09/2019 15:26, Wei Liu wrote: On Thu, Sep 26, 2019 at 10:46:34AM +0100, hong...@amazon.com wrote: From: Hongyan Xia Signed-off-by: Hongyan Xia ---   xen/arch/x86/setup.c    | 4 ++--   xen/common/page_alloc.c | 2 +-   2 files changed,

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 27.09.2019 14:54, hong...@amazon.com wrote: > On 26/09/2019 15:26, Wei Liu wrote: >> On Thu, Sep 26, 2019 at 10:46:34AM +0100, hong...@amazon.com wrote: >>> --- a/xen/arch/x86/setup.c >>> +++ b/xen/arch/x86/setup.c >>> @@ -1367,7 +1367,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)

Re: [Xen-devel] [Vote] XCP-ng subproject proposal

> On 9 Sep 2019, at 15:44, Lars Kurth wrote: > > Hello everyone, > > Olivier had posted an RFC for this proposal on xen-devel@- see > https://xen.markmail.org/thread/ermnrb3ps3okvnjr > > > The proposal also has been discussed by the

Re: [Xen-devel] [PATCH for-next RFC 4/8] x86: factor out xen variants for hypervisor setup code

On 27.09.2019 14:47, Wei Liu wrote: > On Fri, Sep 27, 2019 at 01:39:14PM +0200, Jan Beulich wrote: >> On 27.09.2019 13:30, Wei Liu wrote: >>> On Wed, Sep 25, 2019 at 12:23:54PM +0200, Roger Pau Monné wrote: Also it might be nice to introduce something like: enum guest_type {

Re: [Xen-devel] [RFC PATCH 71/84] x86/setup: start tearing down the direct map.

On 26/09/2019 15:26, Wei Liu wrote: On Thu, Sep 26, 2019 at 10:46:34AM +0100, hong...@amazon.com wrote: From: Hongyan Xia Signed-off-by: Hongyan Xia --- xen/arch/x86/setup.c| 4 ++-- xen/common/page_alloc.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [Xen-devel] [PATCH] iommu: fix PVH dom0 settings

On 27.09.2019 14:28, Roger Pau Monné wrote: > On Fri, Sep 27, 2019 at 12:45:54PM +0100, Paul Durrant wrote: >> --- a/xen/drivers/passthrough/iommu.c >> +++ b/xen/drivers/passthrough/iommu.c >> @@ -154,13 +154,13 @@ custom_param("dom0-iommu", parse_dom0_iommu_param); >> >> static void

Re: [Xen-devel] [PATCH V5] xen/arm: Restrict "p2m_ipa_bits" according to the IOMMU requirements

On 27.09.19 15:38, Julien Grall wrote: On 27/09/2019 13:35, Julien Grall wrote: Hi, Hi Julien, On 27/09/2019 12:57, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko There is a strict requirement for the IOMMU which wants to share the P2M table with the CPU. The IOMMU's Stage-2

Re: [Xen-devel] [PATCH v4 24/46] xen: switch from for_each_vcpu() to for_each_sched_unit()

On 27.09.2019 11:32, Dario Faggioli wrote: > On Fri, 2019-09-27 at 09:00 +0200, Juergen Gross wrote: >> Where appropriate switch from for_each_vcpu() to >> for_each_sched_unit() >> in order to prepare core scheduling. >> >> As it is beneficial once here and for sure in future add a >>

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

Julien Grall writes: > Hi, > > On 27/09/2019 13:27, Volodymyr Babchuk wrote: >> >> Julien Grall writes: >> >>> On 27/09/2019 12:45, Volodymyr Babchuk wrote: Julien, >>> >>> Hi... >>> Julien Grall writes: > At the moment, enter_hypervisor_head() and leave_hypervisor_tail()

Re: [Xen-devel] [PATCH v4 20/46] xen: let vcpu_create() select processor

On 27.09.2019 09:00, Juergen Gross wrote: > Today there are two distinct scenarios for vcpu_create(): either for > creation of idle-domain vcpus (vcpuid == processor) or for creation of > "normal" domain vcpus (including dom0), where the caller selects the > initial processor on a round-robin

Re: [Xen-devel] [PATCH for-next RFC 4/8] x86: factor out xen variants for hypervisor setup code

On Fri, Sep 27, 2019 at 01:39:14PM +0200, Jan Beulich wrote: > On 27.09.2019 13:30, Wei Liu wrote: > > On Wed, Sep 25, 2019 at 12:23:54PM +0200, Roger Pau Monné wrote: > >> Also it might be nice to introduce something like: > >> > >> enum guest_type { > >> XEN_GUEST, > >> } guest_type; > >> >

Re: [Xen-devel] [PATCH RFC for-4.13 09/10] xen/arm: asm: Replace use of ALTERNATIVE with alternative_if

Julien Grall writes: > Hi, > > On 27/09/2019 13:11, Volodymyr Babchuk wrote: >> >> >> Julien Grall writes: >> >>> Using alternative_if makes the code a bit more streamlined. >>> >>> Take the opportunity to use the new auto-nop infrastructure to avoid >>> counting the number of nop in the else

Re: [Xen-devel] [PATCH for-next RFC 4/8] x86: factor out xen variants for hypervisor setup code

On Fri, Sep 27, 2019 at 01:41:59PM +0200, Roger Pau Monné wrote: > > > > > > I wonder, do you also require to map hypervisor data into the guest > > > physmap when running on HyperV? > > > > > > > Yes. There are a lot of comparable concepts in Hyper-V. For example, > > there is a page called VP

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

Hi, On 27/09/2019 13:27, Volodymyr Babchuk wrote: Julien Grall writes: On 27/09/2019 12:45, Volodymyr Babchuk wrote: Julien, Hi... Julien Grall writes: At the moment, enter_hypervisor_head() and leave_hypervisor_tail() are used to deal with actions to be done before/after any guest

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Julien Grall writes: > On 27/09/2019 12:56, Volodymyr Babchuk wrote: >> >> Julien, > > Hi... > >> >> Julien Grall writes: >> >>> At the moment, SSBD workaround is re-enabled for Xen after interrupts >>> are unmasked. This means we may end up to execute some part of the >>> hypervisor if an

Re: [Xen-devel] [PATCH V5] xen/arm: Restrict "p2m_ipa_bits" according to the IOMMU requirements

On 27/09/2019 13:35, Julien Grall wrote: Hi, On 27/09/2019 12:57, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko There is a strict requirement for the IOMMU which wants to share the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal to the P2M IPA size. It is not a

Re: [Xen-devel] [PATCH V5] xen/arm: Restrict "p2m_ipa_bits" according to the IOMMU requirements

Hi, On 27/09/2019 12:57, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko There is a strict requirement for the IOMMU which wants to share the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal to the P2M IPA size. It is not a problem when the IOMMU can support all

Re: [Xen-devel] [PATCH RFC for-4.13 09/10] xen/arm: asm: Replace use of ALTERNATIVE with alternative_if

Hi, On 27/09/2019 13:11, Volodymyr Babchuk wrote: Julien Grall writes: Using alternative_if makes the code a bit more streamlined. Take the opportunity to use the new auto-nop infrastructure to avoid counting the number of nop in the else part for arch/arm/arm64/entry.S Signed-off-by:

Re: [Xen-devel] [PATCH] iommu: fix PVH dom0 settings

On Fri, Sep 27, 2019 at 12:45:54PM +0100, Paul Durrant wrote: > PVH dom0 must operate with the iommu settings in 'strict' mode i.e. only the > domain's own pages will be mapped in the IOMMU. The check_hwdom_reqs() is > supposed to ensure this. Unfortunately the test for a PVH dom0 is made > using

Re: [Xen-devel] [PATCH v7.1 4/4] xen/x86: Allow stubdom access to irq created for msi.

On 26.09.2019 06:05, Marek Marczykowski-Górecki wrote: > Stubdomains need to be given sufficient privilege over the guest which it > provides emulation for in order for PCI passthrough to work correctly. > When a HVM domain try to enable MSI, QEMU in stubdomain calls > PHYSDEVOP_map_pirq, but

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

Julien Grall writes: > On 27/09/2019 12:45, Volodymyr Babchuk wrote: >> >> Julien, > > Hi... > >> Julien Grall writes: >> >>> At the moment, enter_hypervisor_head() and leave_hypervisor_tail() are >>> used to deal with actions to be done before/after any guest request is >>> handled. >>> >>>

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

On 27/09/2019 12:56, Volodymyr Babchuk wrote: Julien, Hi... Julien Grall writes: At the moment, SSBD workaround is re-enabled for Xen after interrupts are unmasked. This means we may end up to execute some part of the hypervisor if an interrupt is received before the workaround is

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

On 27/09/2019 12:45, Volodymyr Babchuk wrote: Julien, Hi... Julien Grall writes: At the moment, enter_hypervisor_head() and leave_hypervisor_tail() are used to deal with actions to be done before/after any guest request is handled. While they are meant to work in pair, the former is

Re: [Xen-devel] [PATCH RFC for-4.13 09/10] xen/arm: asm: Replace use of ALTERNATIVE with alternative_if

Julien Grall writes: > Using alternative_if makes the code a bit more streamlined. > > Take the opportunity to use the new auto-nop infrastructure to avoid > counting the number of nop in the else part for arch/arm/arm64/entry.S > > Signed-off-by: Julien Grall > > --- > This is pretty much

Re: [Xen-devel] [PATCH] iommu: fix PVH dom0 settings

On 27.09.19 14:02, Jan Beulich wrote: On 27.09.2019 13:45, Paul Durrant wrote: PVH dom0 must operate with the iommu settings in 'strict' mode i.e. only the domain's own pages will be mapped in the IOMMU. The check_hwdom_reqs() is supposed to ensure this. Unfortunately the test for a PVH dom0 is

Re: [Xen-devel] [PATCH] iommu: fix PVH dom0 settings

On 27.09.2019 13:45, Paul Durrant wrote: > PVH dom0 must operate with the iommu settings in 'strict' mode i.e. only the > domain's own pages will be mapped in the IOMMU. The check_hwdom_reqs() is > supposed to ensure this. Unfortunately the test for a PVH dom0 is made > using

Re: [Xen-devel] [PATCH] iommu: fix PVH dom0 settings

On 27.09.2019 13:45, Paul Durrant wrote: > PVH dom0 must operate with the iommu settings in 'strict' mode i.e. only the > domain's own pages will be mapped in the IOMMU. The check_hwdom_reqs() is > supposed to ensure this. Unfortunately the test for a PVH dom0 is made > using

Re: [Xen-devel] [PATCH RFC for-4.13 06/10] xen/arm: Move ARCH_PATCH_INSN_SIZE out of the header livepatch.h

On 9/26/19 7:38 PM, Julien Grall wrote: At the moment, ARCH_PATCH_INSN_SIZE is defined in the header livepatch.h. However, this is also used in the alternative code. Rather than including livepatch.h just for using the define, move it in the header insn.h which seems more suitable.

[Xen-devel] [PATCH V5] xen/arm: Restrict "p2m_ipa_bits" according to the IOMMU requirements

From: Oleksandr Tyshchenko There is a strict requirement for the IOMMU which wants to share the P2M table with the CPU. The IOMMU's Stage-2 input size must be equal to the P2M IPA size. It is not a problem when the IOMMU can support all values the CPU supports. In that case, the IOMMU driver

Re: [Xen-devel] [PATCH RFC for-4.13 04/10] xen/arm: Ensure the SSBD workaround is re-enabled right after exiting a guest

Julien, Julien Grall writes: > At the moment, SSBD workaround is re-enabled for Xen after interrupts > are unmasked. This means we may end up to execute some part of the > hypervisor if an interrupt is received before the workaround is > re-enabled. > > As the rest of

Re: [Xen-devel] [PATCH RFC for-4.13 07/10] xen/arm: Allow insn.h to be called from assembly

Julien Grall writes: > A follow-up patch will require to include insn.h from assembly code. So > wee need to protect any C-specific definition to avoid compilation > error when used in assembly code. > > Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babchuk > --- >

Re: [Xen-devel] [PATCH RFC for-4.13 06/10] xen/arm: Move ARCH_PATCH_INSN_SIZE out of the header livepatch.h

Julien Grall writes: > At the moment, ARCH_PATCH_INSN_SIZE is defined in the header > livepatch.h. However, this is also used in the alternative code. > > Rather than including livepatch.h just for using the define, move it in > the header insn.h which seems more suitable. > > Signed-off-by:

Re: [Xen-devel] [PATCH RFC for-4.13 05/10] xen/arm: alternative: Remove unused parameter for alternative_if_not_cap

Julien Grall writes: > The macro alternative_if_not_cap is taking two parameters. The second > parameter is never used and it is hard to see how this can be used > correctly as it is only protecting the alternative section magic. > > Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babchuk

[Xen-devel] [PATCH] iommu: fix PVH dom0 settings

PVH dom0 must operate with the iommu settings in 'strict' mode i.e. only the domain's own pages will be mapped in the IOMMU. The check_hwdom_reqs() is supposed to ensure this. Unfortunately the test for a PVH dom0 is made using paging_mode_translate() and, when commit f89f5558 "remove late

  1   2   3   >