Re: [Xen-devel] [PATCH RFC v1 56/74] xen/pvshim: add grant table operations

>>> On 09.01.18 at 19:34, wrote: > On Mon, Jan 08, 2018 at 10:19:39AM -0700, Jan Beulich wrote: >> >>> On 04.01.18 at 14:06, wrote: >> > +{ >> > +struct gnttab_query_size op; >> > +int rc; >> > + >> > +if ( unlikely(copy_from_guest(&op, uop, 1)) ) >> > +{ >> >

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 10/01/18 04:58, Peter wrote: > On 2018-01-09 15:04, Stefano Stabellini wrote: >> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote: >>> On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote: >>> > On 05/01/18 18:16, Rich Persaud wrote: >>> > >> On Jan 5, 2018, at 06:35, Lars Kurth >>

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 09/01/18 23:11, Hans van Kranenburg wrote: > On 01/09/2018 07:22 PM, Rich Persaud wrote: On Jan 9, 2018, at 12:56, Stefano Stabellini wrote: On Tue, 9 Jan 2018, Doug Goldstein wrote: On 1/9/18 11:33 AM, Jan Beulich wrote: On 09.01.18 at 18:23, wrote: >> O

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 2018-01-10 11:11, Hans van Kranenburg wrote: Since the primary audience for security fixes are production deployments of Xen where customer assets are at risk, is there an estimate for the percentage/size of Xen deployments where PVH (not only Xen 4.10) has already been deployed for product

Re: [Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

On 01/09/2018 09:07 PM, Anthony Liguori wrote: > On Tue, Jan 9, 2018 at 8:46 PM, Sarah Newman wrote: >> vixen-upstream-v2 hangs for us after dumping the e820 map. We're able to >> build and run vixen-upstream-v1. > > Can give me more details about your guest config? I'm happy to take a > look a

Re: [Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

On Tue, Jan 9, 2018 at 8:46 PM, Sarah Newman wrote: > vixen-upstream-v2 hangs for us after dumping the e820 map. We're able to > build and run vixen-upstream-v1. Can give me more details about your guest config? I'm happy to take a look and debug. > My company needs serial input. It looks like

Re: [Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

vixen-upstream-v2 hangs for us after dumping the e820 map. We're able to build and run vixen-upstream-v1. My company needs serial input. It looks like that wasn't implemented. If so, and nobody else is working on patches to enable serial input, I believe we can come up with something in the next

[Xen-devel] [qemu-mainline test] 117732: tolerable FAIL - PUSHED

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

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 2018-01-09 15:04, Stefano Stabellini wrote: On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote: On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote: > On 05/01/18 18:16, Rich Persaud wrote: > >> On Jan 5, 2018, at 06:35, Lars Kurth >> > wrote: > >

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Tue, Jan 09, 2018 at 11:47:54PM +, Andrew Cooper wrote: >On 08/01/18 04:01, Chao Gao wrote: >> Define interface, structures and hypercalls for toolstack to build >> cpu topology and for guest that will retrieve it [1]. >> Two subop hypercalls introduced by this patch: >> XEN_DOMCTL_set_cpu_t

Re: [Xen-devel] [PATCH 2/2] xen/gntdev: Fix partial gntdev_mmap() cleanup

On 01/09/2018 07:10 AM, Ross Lagerwall wrote: When cleaning up after a partially successful gntdev_mmap(), unmap the successfully mapped grant pages otherwise Xen will kill the domain if in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will kill the process and emit "BUG: Bad

Re: [Xen-devel] [PATCH 1/2] xen/gntdev: Fix off-by-one error when unmapping with holes

On 01/09/2018 07:10 AM, Ross Lagerwall wrote: If the requested range has a hole, the calculation of the number of pages to unmap is off by one. Fix it. Signed-off-by: Ross Lagerwall Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-dev

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Tue, Jan 09, 2018 at 12:18:13PM -0500, Daniel De Graaf wrote: >On 01/09/2018 04:06 AM, Chao Gao wrote: >> On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote: >> > On 01/07/2018 11:01 PM, Chao Gao wrote: >> > > Define interface, structures and hypercalls for toolstack to build >> > >

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 01/09/2018 01:57 PM, Matt Wilson wrote: > Let me know if you need any help with the sidecar script. Generally > it's straightforward enough to build so I'm sure you won't have any > trouble. Here's one that I used for local testing on my laptop in a > CentOS-ish chroot (we have other bits respon

[Xen-devel] [qemu-upstream-unstable test] 117731: trouble: broken/fail/pass

flight 117731 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117731/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub broken test-amd6

[Xen-devel] [seabios test] 117733: regressions - FAIL

flight 117733 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/117733/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not suc

[Xen-devel] [PATCH v3 18/24] vixen: Introduce ECS_PROXY for event channel proxying

From: Jan H. Schönherr Previously, we would keep proxied event channels as ECS_INTERDOMAIN channel around. This works for most things, but has the problem that EVTCHNOP_status is broken, and that EVTCHNOP_close does not mark an event channel as free. Introduce a separate ECS_PROXY to denote even

[Xen-devel] [PATCH v3 09/24] vixen: modify the e820 table to advertise HVM special pages as RAM

From: Anthony Liguori In order to be able to assign the Xenstore page into the Vixen guest, we need struct page_info's to exist. We do this by modifying the e820 table early in boot and then using the badpages handling to prevent these pages from being added to the xenheap. Since these pages ex

[Xen-devel] [PATCH v3 16/24] vixen: pass grant table operations through to the outer Xen

From: Anthony Liguori The grant table is a region of guest memory that contains GMFNs which in PV are MFNs but are PFNs in HVM. Since a Vixen guest MFN is an HVM PFN, we can pass this table directly through to the outer Xen which cuts down considerably on overhead. We do not forward most of the

[Xen-devel] [PATCH v3 13/24] vixen: Use SCHEDOP_shutdown to shutdown the machine

From: Jan H. Schönherr While the hwdom_shutdown() is able to reboot the system, it fails to properly power it off. With SCHEDOP_shutdown, we delegate the problem. Signed-off-by: Jan H. Schönherr --- xen/common/domain.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/xen/com

[Xen-devel] [PATCH v3 20/24] vixen: event channel passthrough support

From: Anthony Liguori For Vixen, we do not want to pass through all event channel operations as HVM guests do not have nearly as many event channel interactions as PV and on older versions of Xen, there is no reliable way to wake up an event channel on VCPU != 0 leading to a variety of deadlocks.

[Xen-devel] [PATCH v3 07/24] vixen: introduce is_vixen() to allow altering behavior

From: Anthony Liguori Vixen (Virtualized Xen) is a paravirtual mode of Xen where paravirtual I/O is passed through from the parent hypervisor all the way through the dom0 guest. The dom0 guest is also deprivileged and renumbered to give the appearance that it is running as a normal PV guest. Si

[Xen-devel] [PATCH v3 03/24] x86/guest: Hypercall support

From: Andrew Cooper Signed-off-by: Andrew Cooper --- xen/arch/x86/guest/Makefile | 1 + xen/arch/x86/guest/hypercall_page.S | 79 ++ xen/arch/x86/guest/xen.c | 5 ++ xen/arch/x86/xen.lds.S| 1 + xen/include/asm-x86/guest.h

[Xen-devel] [PATCH v3 19/24] vixen: Fix Vixen adaptation of send_global_virq()

From: Jan H. Schönherr The function originally did the following unconditionally: send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq); The new variant should reflect the non-Vixen case correctly. Signed-off-by: Jan H. Schönherr Signed-off-by: Anthony Liguori --- x

[Xen-devel] [PATCH v3 21/24] vixen: provide Xencons implementation

From: Anthony Liguori Our initial approach exposed the console ring directly to guests which worked well except for the fact that very old versions of Xen did not support console ring for HVM guests. It also proved to be complicated from a management tool perspective since both the serial consol

[Xen-devel] [PATCH v3 24/24] xen/pvshim: memory hotplug

From: Roger Pau Monne Signed-off-by: Roger Pau Monné Signed-off-by: Anthony Liguori --- v2 -> v3 - adapted for Vixen --- xen/arch/x86/guest/vixen.c| 110 ++ xen/common/memory.c | 14 + xen/include/asm-x86/guest/vixen.h | 4 ++ 3

[Xen-devel] [PATCH v3 17/24] vixen: setup infrastructure to receive event channel notifications

From: Anthony Liguori This patch registers an interrupt handler using either an INTx interrupt from the platform PCI device, CALLBACK_IRQ vector delivery, or evtchn_upcall_vector depending on what the parent hypervisor supports. The event channel polling code comes from Linux but uses the intern

[Xen-devel] [PATCH v3 22/24] vixen: dom0 builder support

From: Anthony Liguori The dom0 builder requires a number of modifications in order to be able to launch unprivileged guests. The console and store pages must be mapped in a specific location within the guest's initial page table. We also have to setup the start info to be what's expected for un

[Xen-devel] [PATCH v3 12/24] vixen: paravirtualization TSC frequency calculation

From: Anthony Liguori Otherwise when time sharing a physical CPU, the calculation can be bogus resulting in time drift for the guest due to improper frequency within pvclock. Signed-off-by: Anthony Liguori --- xen/arch/x86/guest/vixen.c| 22 ++ xen/arch/x86/time.c

[Xen-devel] [PATCH v3 14/24] vixen: forward VCPUOP_register_runstate_memory_area to outer Xen

From: Anthony Liguori This allows for proper accounting of steal time within the guest. Signed-off-by: Anthony Liguori --- xen/common/domain.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/common/domain.c b/xen/common/domain.c index ede377c..780f8ff 100644 --- a/xen/common/doma

[Xen-devel] [PATCH v3 11/24] vixen: early initialization of Vixen including shared_info mapping

From: Anthony Liguori We split initialization of Vixen into two parts. The first part just detects the presence of an HVM hypervisor so that we can figure out whether to modify the e820 table. The later initialization is used to actually map the shared_info structure from the parent hypervisor

[Xen-devel] [PATCH v3 15/24] vixen: pass through version hypercalls to parent Xen

From: Anthony Liguori This is necessary to trigger event channel upcalls but it is also useful to passthrough the full version information such that the guest believes it is running on the parent Xen. Signed-off-by: Matt Wilson Signed-off-by: Anthony Liguori --- v1 -> v2 - don't pass through

[Xen-devel] [PATCH v3 23/24] vixen: use default position for the m2p mappings

From: Roger Pau Monne When running a 32bit kernel as Dom0 on a 64bit hypervisor the hypervisor will try to shrink the hypervisor hole to the minimum needed, and thus requires the Dom0 to use XENMEM_machphys_mapping in order to fetch the position of the start of the hypervisor virtual mappings. D

[Xen-devel] [PATCH v3 05/24] char: optionally redirect {, g}printk output to QEMU debug log

From: Matt Wilson When using Vixen, it is helpful to get the Xen messages in a separate channel than the console output. Add an option to output to the QEMU backdoor logging port. Signed-off-by: Matt Wilson --- v1 -> v2 - #ifdef for !x86_64 --- xen/drivers/char/console.c | 35 +++

[Xen-devel] [PATCH v3 02/24] x86/entry: Probe for Xen early during boot

From: Andrew Cooper Signed-off-by: Andrew Cooper --- v1 -> v2 - ARM stubs --- xen/arch/x86/Makefile | 1 + xen/arch/x86/guest/Makefile | 1 + xen/arch/x86/guest/xen.c| 75 + xen/arch/x86/setup.c| 4 +++ xen/include/as

[Xen-devel] [PATCH v3 06/24] console: do not print banner if below info log threshold

From: Anthony Liguori Only print the banner if the log threshold is at least info. For Vixen guests, we want the console output to be exactly what the PV guest would show on it's own. That means the inner Xen banner can potentially break automation that assumes a specific type of console output

[Xen-devel] [PATCH v3 08/24] vixen: allow dom0 to be created with a domid != 0

From: Anthony Liguori Some older guests special case domid=0 instead of checking the shared info flags so in order to get PV drivers loaded properly, we need to make the guest always appear with a domid != 0. While the Vixen domain is the hardware domain, we don't want it to behave that way so w

[Xen-devel] [PATCH v3 10/24] vixen: do not permit access to physical IRQs if in Vixen mode

From: Anthony Liguori Our intention is for the Vixen guest to be deprivileged so we need to avoid permitting access to each IRQ even though it is technically the hardware domain. Signed-off-by: Anthony Liguori --- xen/arch/x86/irq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[Xen-devel] [PATCH v3 00/24] Vixen: A PV-in-HVM shim

From: Anthony Liguori CVE-2017-5754 is problematic for paravirtualized x86 domUs because it appears to be very difficult to isolate the hypervisor's page tables from PV domUs while maintaining ABI compatibility. Instead of trying to make a KPTI-like approach work for Xen PV, it seems reasonable

[Xen-devel] [PATCH v3 01/24] ---- x86/Kconfig: Options for Xen and PVH support

From: Andrew Cooper Signed-off-by: Andrew Cooper --- xen/arch/x86/Kconfig | 17 + 1 file changed, 17 insertions(+) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 7c45829..07530bf 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -117,6 +117,23 @@ c

[Xen-devel] [PATCH v3 04/24] x86: Don't use potentially incorrect CPUID values for topology information

From: Jan H. Schönherr Intel says for CPUID leaf 0Bh: "Software must not use EBX[15:0] to enumerate processor topology of the system. This value in this field (EBX[15:0]) is only intended for display/diagnostic purposes. The actual number of logical processors available to BIOS/OS/

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On 08/01/18 04:01, Chao Gao wrote: > Define interface, structures and hypercalls for toolstack to build > cpu topology and for guest that will retrieve it [1]. > Two subop hypercalls introduced by this patch: > XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain > and XENMEM_g

Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

On Fri, 5 Jan 2018, Juergen Gross wrote: > On 04/01/18 21:21, Andrew Cooper wrote: > > This work was developed as an SP3 mitigation, but shelved when it became > > clear > > that it wasn't viable to get done in the timeframe. > > > > To protect against SP3 attacks, most mappings needs to be flush

Re: [Xen-devel] [BUG] unable to shutdown (page fault in mwait_idle()/do_dbs_timer()/__find_next_bit()) (fwd)

Hello. On Tue, 9 Jan 2018, Jan Beulich wrote: On 08.01.18 at 17:07, wrote: On Mon, 8 Jan 2018, Jan Beulich wrote: On 07.01.18 at 13:34, wrote: (XEN) [ Xen-4.10.0-vgpu x86_64 debug=n Not tainted ] The -vgpu tag makes me wonder whether you have any patches in your tree on top of

[Xen-devel] [qemu-upstream-4.10-testing test] 117730: regressions - FAIL

flight 117730 qemu-upstream-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/117730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 117345 Regr

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 01/09/2018 07:22 PM, Rich Persaud wrote: >>> On Jan 9, 2018, at 12:56, Stefano Stabellini wrote: >>> >>> On Tue, 9 Jan 2018, Doug Goldstein wrote: >>> On 1/9/18 11:33 AM, Jan Beulich wrote: >>> On 09.01.18 at 18:23, wrote: > On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini > wro

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 09, 2018 at 05:58:46PM +, Wei Liu wrote: > > Ian has been busy writing the sidecar script and Roger and I have been > working on cleaning up the branch. We want to post a new version as > soon as possible (tomorrow or even tonight). Ian, Let me know if you need any help with the

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 9, 2018 at 11:43 AM, Wei Liu wrote: > On Mon, Jan 08, 2018 at 05:45:32PM +, Ian Jackson wrote: >> AIUI we have a series for pv-in-pvh shim which is nearing completion >> in the sense that it will have been well-tested (especially the >> hypervisor parts) and has good functionality.

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

Hi Jan, On 01/02/2018 04:35 PM, Jan Beulich wrote: On 21.12.17 at 15:55, wrote: The EFI image should be relocatable. At the moment, all the stub is relocatable but one place. Do you really mean relocatable here? Based on ... Hmm yes position independent. On both Arm64 and x86-64 (from

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Mon, Jan 08, 2018 at 05:45:32PM +, Ian Jackson wrote: > AIUI we have a series for pv-in-pvh shim which is nearing completion > in the sense that it will have been well-tested (especially the > hypervisor parts) and has good functionality. (Wei is handling the > assembly of this series.) >

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

On 09/01/18 20:13, Andrew Cooper wrote: > (sorry for the top-post. I'm on my phone) > > I can see you are using ltr, but I don't see anywhere where where you are > changing the content on the TSS, or the top-of-stack content. The per-vcpu TSS is already initialized with the correct stack addres

[Xen-devel] [xen-unstable test] 117727: FAIL

flight 117727 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/117727/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt broken in 117696 Tests whi

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

(sorry for the top-post. I'm on my phone) I can see you are using ltr, but I don't see anywhere where where you are changing the content on the TSS, or the top-of-stack content. It is very complicated to safely switch IST stacks when you might be taking interrupts. ~Andrew _

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-x

[Xen-devel] [linux-next test] 117724: regressions - FAIL

flight 117724 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/117724/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 117694 test-amd64-i386-exam

Re: [Xen-devel] [PATCH RFC v1 56/74] xen/pvshim: add grant table operations

On Mon, Jan 08, 2018 at 10:19:39AM -0700, Jan Beulich wrote: > >>> On 04.01.18 at 14:06, wrote: > > @@ -30,11 +31,17 @@ > > #include > > #include > > > > +#include > > Interesting: The event channel patch gave me the impression that > it is not intended to deal with 32-bit guests. AFAICT

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

>> On Jan 9, 2018, at 12:56, Stefano Stabellini wrote: >> >> On Tue, 9 Jan 2018, Doug Goldstein wrote: >> On 1/9/18 11:33 AM, Jan Beulich wrote: >> On 09.01.18 at 18:23, wrote: On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini wrote: >>> On Tue, 9 Jan 2018, George Dunlap wrot

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 01/09/2018 06:13 PM, Doug Goldstein wrote: > On 1/8/18 11:45 AM, Ian Jackson wrote: >> But this is not a usual situation. This time, we don't have the time >> to wait. >> >> Opinions ? > > I'm going to follow up with a top post with my feelings and from info on > various parts of the thread. >

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 1/8/18 11:45 AM, Ian Jackson wrote: > But this is not a usual situation. This time, we don't have the time > to wait. > > Opinions ? I'm going to follow up with a top post with my feelings and from info on various parts of the thread. We have 2 versions of PV shim, the Citrix version and the

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 09, 2018 at 11:59:01AM -0600, Doug Goldstein wrote: > On 1/9/18 5:50 AM, Wei Liu wrote: > > > > We haven't tested booting the series I posted in HVM mode, but off the > > top of my head it should work in HVM mode as well -- the multiboot path > > is left intact. > > > > Can we actual

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 09, 2018 at 09:23:03AM -0800, Anthony Liguori wrote: > On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini > wrote: > > On Tue, 9 Jan 2018, George Dunlap wrote: > >> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: > >> > On a similarly pragmatic note: would a variation of Anthony's

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 1/9/18 5:50 AM, Wei Liu wrote: > > We haven't tested booting the series I posted in HVM mode, but off the > top of my head it should work in HVM mode as well -- the multiboot path > is left intact. > Can we actually do this before committing to this series? I've seen a number of "this should

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, 9 Jan 2018, Doug Goldstein wrote: > On 1/9/18 11:33 AM, Jan Beulich wrote: > On 09.01.18 at 18:23, wrote: > >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini > >> wrote: > >>> On Tue, 9 Jan 2018, George Dunlap wrote: > On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: > >

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 1/8/18 3:44 PM, Anthony Liguori wrote: > > It's not particularly hard to plumb through I think but if you are > using PCI passthrough for PV, then you really shouldn't worry about > Spectre/Meltdown. That PV guest can already read all of physical > memory (since no IOMMU is used) and they can

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On 1/9/18 11:33 AM, Jan Beulich wrote: On 09.01.18 at 18:23, wrote: >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini >> wrote: >>> On Tue, 9 Jan 2018, George Dunlap wrote: On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: > On a similarly pragmatic note: would a variation of

Re: [Xen-devel] [PATCH RFC v1 55/74] xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU

On Mon, Jan 8, 2018 at 8:05 AM, Jan Beulich wrote: On 04.01.18 at 14:06, wrote: >> From: Roger Pau Monne >> >> Note that the unmask and the virq operations are handled by the shim >> itself, and that FIFO event channels are not exposed to the guest. >> >> Signed-off-by: Anthony Liguori >>

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 9, 2018 at 9:33 AM, Jan Beulich wrote: On 09.01.18 at 18:23, wrote: >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini >> wrote: >>> On Tue, 9 Jan 2018, George Dunlap wrote: On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: > On a similarly pragmatic note: would

Re: [Xen-devel] [PATCH RFC v1 55/74] xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU

>>> On 09.01.18 at 17:45, wrote: > On Tue, Jan 09, 2018 at 01:00:10AM -0700, Jan Beulich wrote: >> >>> On 08.01.18 at 17:22, wrote: >> > On Mon, Jan 08, 2018 at 09:05:40AM -0700, Jan Beulich wrote: >> >> >>> On 04.01.18 at 14:06, wrote: >> >> > +unsigned long evtchn = >> >> > xchg(&XEN_

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

On 09/01/18 18:01, Andrew Cooper wrote: > On 09/01/18 14:27, Juergen Gross wrote: >> Instead of using the TSS and stacks of the physical processor allocate >> them per vcpu, map them in the per domain area, and use those. >> >> Signed-off-by: Juergen Gross > > I don't see anything here which upda

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

>>> On 09.01.18 at 18:23, wrote: > On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini > wrote: >> On Tue, 9 Jan 2018, George Dunlap wrote: >>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: >>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch > series be suitable

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini wrote: > On Tue, 9 Jan 2018, George Dunlap wrote: >> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: >> > On a similarly pragmatic note: would a variation of Anthony's vixen patch >> > series be suitable for pre-PVH Xen 4.6 - 4.9? These ver

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

On 09/01/18 17:38, Boris Ostrovsky wrote: > On 01/09/2018 11:31 AM, Sander Eikelenboom wrote: >> On 09/01/18 17:16, Pavel Tatashin wrote: >>> Hi Juergen, >>> >>> Do you have this patch applied: >>> >>> https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be >> Seems this h

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On 01/09/2018 04:06 AM, Chao Gao wrote: On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote: On 01/07/2018 11:01 PM, Chao Gao wrote: Define interface, structures and hypercalls for toolstack to build cpu topology and for guest that will retrieve it [1]. Two subop hypercalls introduc

Re: [Xen-devel] [PATCH RFC v1 21/74] x86/entry: Early PVH boot code

On Tue, Jan 09, 2018 at 09:41:51AM -0700, Jan Beulich wrote: > >>> On 09.01.18 at 16:45, wrote: > > On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote: > >> > +pvh_mbi.mods_count = pvh_info->nr_modules; > >> > +pvh_mbi.mods_addr = __pa(pvh_mbi_mods); > >> > + > >> > +mod = pvh

[Xen-devel] PVH backports to 4.9 and 4.8

Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people able to run PVH kernels to switch their PV guests directly to PVH guests; and second, eventually enable the backport of patches which will enable transparent chan

Re: [Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

On 09/01/18 14:27, Juergen Gross wrote: > Instead of using the TSS and stacks of the physical processor allocate > them per vcpu, map them in the per domain area, and use those. > > Signed-off-by: Juergen Gross I don't see anything here which updates the fields in the TSS across context switch. 

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, 9 Jan 2018, George Dunlap wrote: > On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote: > > On a similarly pragmatic note: would a variation of Anthony's vixen patch > > series be suitable for pre-PVH Xen 4.6 - 4.9? These versions are currently > > documented as security-supported (Oct 2

Re: [Xen-devel] [PATCH RFC v1 55/74] xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU

On Tue, Jan 09, 2018 at 01:00:10AM -0700, Jan Beulich wrote: > >>> On 08.01.18 at 17:22, wrote: > > On Mon, Jan 08, 2018 at 09:05:40AM -0700, Jan Beulich wrote: > >> >>> On 04.01.18 at 14:06, wrote: > >> > +unsigned long evtchn = > >> > xchg(&XEN_shared_info->evtchn_pending[l1], 0); > >>

[Xen-devel] [PATCH] x86/ioemul: Account for ioemul_handle_quirk() in stub length check

The opcode potentially written into ctxt->io_emul_stub[] in the case that ioemul_handle_quirk() is overriding the default logic isnt accounted for in the build-time check that the stubs are large enough. Introduce IOEMUL_QUIRK_STUB_BYTES and use for both the main and quirk stub cases. As a slim o

Re: [Xen-devel] [PATCH RFC v1 21/74] x86/entry: Early PVH boot code

>>> On 09.01.18 at 16:45, wrote: > On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote: >> > +pvh_mbi.mods_count = pvh_info->nr_modules; >> > +pvh_mbi.mods_addr = __pa(pvh_mbi_mods); >> > + >> > +mod = pvh_mbi_mods; >> > +entry = __va(pvh_info->modlist_paddr); >> >> How co

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

On 01/09/2018 11:31 AM, Sander Eikelenboom wrote: > On 09/01/18 17:16, Pavel Tatashin wrote: >> Hi Juergen, >> >> Do you have this patch applied: >> >> https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be > Seems this hasn't made it to Linus yet ? > > I will give it a t

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

On 09/01/18 17:16, Pavel Tatashin wrote: > Hi Juergen, > > Do you have this patch applied: > > https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be Seems this hasn't made it to Linus yet ? I will give it a test and report back, thanks ! > > Thank you, > Pavel > >

Re: [Xen-devel] [PATCH RFC v1 21/74] x86/entry: Early PVH boot code

On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote: > > +module_t *mod; > > +unsigned int i; > > + > > +ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE); > > + > > +/* > > + * Turn hvm_start_info into mbi. Luckily all modules are placed under > > 4GB > > + * bo

Re: [Xen-devel] [PATCH RFC v1 54/74] xen/pvshim: set correct domid value

On Mon, Jan 08, 2018 at 07:17:16AM -0700, Jan Beulich wrote: > >>> On 04.01.18 at 14:06, wrote: > > @@ -576,11 +578,11 @@ static void noinline init_done(void) > > > > system_state = SYS_STATE_active; > > > > +domain_unpause_by_systemcontroller(dom0); > > + > > /* MUST be done pri

Re: [Xen-devel] [PATCH RFC v1 57/74] x86/pv-shim: shadow PV console's page for L2 DomU

>>> On 09.01.18 at 16:43, wrote: > On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote: >> > > > On 04.01.18 at 14:06, wrote: >> > +size_t consoled_guest_rx(void) >> > +{ >> > +size_t recv = 0, idx = 0; >> > +XENCONS_RING_IDX cons, prod; >> > + >> > +if ( !cons_ring ) >> > +r

Re: [Xen-devel] [PATCH RFC v1 53/74] xen/pvshim: modify Dom0 builder in order to build a DomU

>>> On 09.01.18 at 17:09, wrote: > On Mon, Jan 08, 2018 at 07:06:14AM -0700, Jan Beulich wrote: >> >>> On 04.01.18 at 14:06, wrote: >> > From: Roger Pau Monne >> > --- a/xen/arch/x86/pv/dom0_build.c >> > +++ b/xen/arch/x86/pv/dom0_build.c >> > @@ -31,9 +31,8 @@ >> > #define L3_PROT (BASE_PROT|_

Re: [Xen-devel] [BUG] unable to shutdown (page fault in mwait_idle()/do_dbs_timer()/__find_next_bit()) (fwd)

>>> On 08.01.18 at 17:07, wrote: > On Mon, 8 Jan 2018, Jan Beulich wrote: > On 07.01.18 at 13:34, wrote: >>> (XEN) [ Xen-4.10.0-vgpu x86_64 debug=n Not tainted ] >> >> The -vgpu tag makes me wonder whether you have any patches in >> your tree on top of plain 4.10.0 (or 4.10-stagin

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

Hi Juergen, Do you have this patch applied: https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be Thank you, Pavel On 01/09/2018 11:10 AM, Juergen Gross wrote: On 09/01/18 16:29, Sander Eikelenboom wrote: Since it's already rc7: "Give me a subtle ping, Vasili. One

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

On 09/01/18 16:29, Sander Eikelenboom wrote: > Since it's already rc7: > "Give me a subtle ping, Vasili. One subtle ping only, please." I like that film :-) Pavel, can you please comment? Do you have an idea how to repair the issue or should we revert your patch in 4.15? Juergen > > On 04/01/

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote: >On 01/07/2018 11:01 PM, Chao Gao wrote: >> Define interface, structures and hypercalls for toolstack to build >> cpu topology and for guest that will retrieve it [1]. >> Two subop hypercalls introduced by this patch: >> XEN_DOMCTL_se

Re: [Xen-devel] [PATCH RFC v1 53/74] xen/pvshim: modify Dom0 builder in order to build a DomU

On Mon, Jan 08, 2018 at 07:06:14AM -0700, Jan Beulich wrote: > >>> On 04.01.18 at 14:06, wrote: > > From: Roger Pau Monne > > --- a/xen/arch/x86/pv/dom0_build.c > > +++ b/xen/arch/x86/pv/dom0_build.c > > @@ -31,9 +31,8 @@ > > #define L3_PROT (BASE_PROT|_PAGE_DIRTY) > > #define L4_PROT (BASE_PRO

Re: [Xen-devel] [PATCH RFC v1 57/74] x86/pv-shim: shadow PV console's page for L2 DomU

On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote: > > > > On 04.01.18 at 14:06, wrote: > > +size_t consoled_guest_rx(void) > > +{ > > +size_t recv = 0, idx = 0; > > +XENCONS_RING_IDX cons, prod; > > + > > +if ( !cons_ring ) > > +return 0; > > + > > +spin_lock(&rx_lock);

Re: [Xen-devel] Linux 4.15-rc6 + xen-unstable: BUG: unable to handle kernel NULL pointer dereference at (null), [ 0.000000] IP: zero_resv_unavail+0x8e/0xe1

Since it's already rc7: "Give me a subtle ping, Vasili. One subtle ping only, please." On 04/01/18 21:02, Sander Eikelenboom wrote: > On 04/01/18 12:44, Juergen Gross wrote: >> On 04/01/18 11:17, Sander Eikelenboom wrote: >>> Hi Boris / Juergen, >>> >>> First of all best wishes for a quite turbule

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

On Tue, Jan 9, 2018 at 2:49 AM, Ian Jackson wrote: > Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as > 4.10.1"): >> Does this sound fair? > > Everything is on fire. Your proposal seems much less radical than > mine. I doubt it will produce a release to our users tomor

Re: [Xen-devel] [PATCH RFC v1 32/74] x86: don't swallow the first command line item in pvh mode

On Thu, Jan 04, 2018 at 01:05:43PM +, Wei Liu wrote: > Instead, special case GRUB1 rather assuming that all bootloaders except GRUB2 > need a parameter stripping. The FreeBSD loader also prepends "xen.gz" (or the Xen kernel filename) to the command line. Hence this change will break it. Roger

Re: [Xen-devel] [PATCH v6.5 20/26] x86: Protect unaware domains from meddling hyperthreads

>>> On 09.01.18 at 15:21, wrote: > On 04/01/18 09:59, Jan Beulich wrote: > On 04.01.18 at 01:15, wrote: >>> Signed-off-by: Andrew Cooper >> Fundamentally (as before) >> Reviewed-by: Jan Beulich >> However: >> >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -2027,6 +20

[Xen-devel] [PATCH RFC 3/4] xen/x86: split context_switch()

Split up context_switch() to prepare switching of the used stack. Signed-off-by: Juergen Gross --- xen/arch/x86/domain.c | 67 --- 1 file changed, 37 insertions(+), 30 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index d

[Xen-devel] [PATCH RFC 2/4] xen/x86: add helper for stack guard

Instead of open coding the calculation of the stack guard page multiple times add a helper to do the calculation. Signed-off-by: Juergen Gross --- xen/arch/x86/mm.c| 8 ++-- xen/include/asm-x86/mm.h | 6 ++ 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/xen/arch/x

[Xen-devel] [PATCH RFC 4/4] xen: use per-vcpu TSS and stacks for pv domains

Instead of using the TSS and stacks of the physical processor allocate them per vcpu, map them in the per domain area, and use those. Signed-off-by: Juergen Gross --- xen/arch/x86/domain.c| 45 +++ xen/arch/x86/pv/domain.c | 72

[Xen-devel] [PATCH RFC 0/4] xen/x86: use per-vcpu stacks for 64 bit pv domains

As a preparation for doing page table isolation in the Xen hypervisor in order to mitigate "Meltdown" use dedicated stacks for 64 bit PV domains mapped to the per-domain virtual area. The TSS is added to that area, too, and the GDT is no longer a remapped version of the per physical cpu one. This

  1   2   >