Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header

On 04/09/17 11:15, Jan Beulich wrote: On 04.09.17 at 10:17, wrote: >> On 03/09/17 10:38, Nicolas Iooss wrote: >>> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >>> shared_info is initialized") moved xen_init_time_ops() from __init to >>> __ref without

Re: [Xen-devel] [PATCH 1/1] x86/xen: fix section of xen_init_time_ops() in header

On 04/09/17 11:15, Jan Beulich wrote: On 04.09.17 at 10:17, wrote: >> On 03/09/17 10:38, Nicolas Iooss wrote: >>> Commit d162809f85b4 ("xen/x86: Do not call xen_init_time_ops() until >>> shared_info is initialized") moved xen_init_time_ops() from __init to >>> __ref without updating

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On 14/08/2017 06:53, Andy Lutomirski wrote: > On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote: >> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: >>> /* Normal 64-bit system call target */ >>> ENTRY(xen_syscall_target) >>> - undo_xen_syscall

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On 14/08/2017 06:53, Andy Lutomirski wrote: > On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote: >> On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: >>> /* Normal 64-bit system call target */ >>> ENTRY(xen_syscall_target) >>> - undo_xen_syscall >>> - jmp

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 11:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 11:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote >> TLB

Re: [Xen-devel] [PATCH v2 3/3] xen: fix hvm guest with kaslr enabled

On 28/07/17 11:23, Juergen Gross wrote: > A Xen HVM guest running with KASLR enabled will die rather soon today > due to the shared info page mapping is using va() too early. This was As a minor grammar issue, either s/due to/because/ or s/mapping is using/mapping using/ ~Andrew > introduced by

Re: [Xen-devel] [PATCH v2 3/3] xen: fix hvm guest with kaslr enabled

On 28/07/17 11:23, Juergen Gross wrote: > A Xen HVM guest running with KASLR enabled will die rather soon today > due to the shared info page mapping is using va() too early. This was As a minor grammar issue, either s/due to/because/ or s/mapping is using/mapping using/ ~Andrew > introduced by

Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame

On 08/08/17 08:02, Juergen Gross wrote: > On 07/08/17 22:56, Boris Ostrovsky wrote: >>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>> index 811e4ddb3f37..a3dcd83187ce 100644 >>> --- a/arch/x86/xen/enlighten_pv.c >>> +++ b/arch/x86/xen/enlighten_pv.c >>> @@ -579,6

Re: [Xen-devel] [PATCH v3] xen: get rid of paravirt op adjust_exception_frame

On 08/08/17 08:02, Juergen Gross wrote: > On 07/08/17 22:56, Boris Ostrovsky wrote: >>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>> index 811e4ddb3f37..a3dcd83187ce 100644 >>> --- a/arch/x86/xen/enlighten_pv.c >>> +++ b/arch/x86/xen/enlighten_pv.c >>> @@ -579,6

Re: [Xen-devel] [PATCH v2] xen: get rid of paravirt op adjust_exception_frame

On 01/08/2017 20:45, Andy Lutomirski wrote: > Also, IMO it would be nice to fully finish the job. Remaining steps are: > > 1. Unsuck the SYSCALL entries on Xen PV. > 2. Unsuck the SYENTER entry on Xen PV. > 3. Make a xen_nmi that's actually correct (should be trivial) > > #1 is here: > >

Re: [Xen-devel] [PATCH v2] xen: get rid of paravirt op adjust_exception_frame

On 01/08/2017 20:45, Andy Lutomirski wrote: > Also, IMO it would be nice to fully finish the job. Remaining steps are: > > 1. Unsuck the SYSCALL entries on Xen PV. > 2. Unsuck the SYENTER entry on Xen PV. > 3. Make a xen_nmi that's actually correct (should be trivial) > > #1 is here: > >

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 15:09, Andy Lutomirski wrote: > On Wed, Jul 26, 2017 at 7:01 AM, Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> On 26/07/17 14:48, Andy Lutomirski wrote: >>>> /* Runs on exception stack */ >>>> -ENTRY(nmi) >>>> -

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 15:09, Andy Lutomirski wrote: > On Wed, Jul 26, 2017 at 7:01 AM, Andrew Cooper > wrote: >> On 26/07/17 14:48, Andy Lutomirski wrote: >>>> /* Runs on exception stack */ >>>> -ENTRY(nmi) >>>> - /* >>&g

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 14:48, Andy Lutomirski wrote: > >> /* Runs on exception stack */ >> -ENTRY(nmi) >> - /* >> -* Fix up the exception frame if we're on Xen. >> -* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most >> -* one value to the stack on native, so it may

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 14:48, Andy Lutomirski wrote: > >> /* Runs on exception stack */ >> -ENTRY(nmi) >> - /* >> -* Fix up the exception frame if we're on Xen. >> -* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most >> -* one value to the stack on native, so it may

Re: [Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket command

On 22/06/17 19:29, Stefano Stabellini wrote: > On Thu, 22 Jun 2017, Roger Pau Monné wrote: >> On Wed, Jun 21, 2017 at 01:16:56PM -0700, Stefano Stabellini wrote: >>> On Tue, 20 Jun 2017, Roger Pau Monné wrote: On Thu, Jun 15, 2017 at 12:09:36PM -0700, Stefano Stabellini wrote: > Just

Re: [Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket command

On 22/06/17 19:29, Stefano Stabellini wrote: > On Thu, 22 Jun 2017, Roger Pau Monné wrote: >> On Wed, Jun 21, 2017 at 01:16:56PM -0700, Stefano Stabellini wrote: >>> On Tue, 20 Jun 2017, Roger Pau Monné wrote: On Thu, Jun 15, 2017 at 12:09:36PM -0700, Stefano Stabellini wrote: > Just

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On 20/06/2017 21:14, Daniel Kiper wrote: > Current approach, wholesale efi struct initialization from efi_xen, is not > good. Usually if new member is defined then it is properly initialized in > drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened > a few times until

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On 20/06/2017 21:14, Daniel Kiper wrote: > Current approach, wholesale efi struct initialization from efi_xen, is not > good. Usually if new member is defined then it is properly initialized in > drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened > a few times until

Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path

On 14/06/17 18:40, Andy Lutomirski wrote: > On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst <brge...@gmail.com> wrote: >> Since tasks using IOPL are very rare, move the switching code to the slow >> path for lower impact on normal tasks. > I think that Andrew Cooper added a vm

Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path

On 14/06/17 18:40, Andy Lutomirski wrote: > On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst wrote: >> Since tasks using IOPL are very rare, move the switching code to the slow >> path for lower impact on normal tasks. > I think that Andrew Cooper added a vmassist that we could opt

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 09/06/17 19:43, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >>> basis, although (as far as I am aware) Xen as a whole would be able to >>> encompass itself and all of its PV guests inside one single SME >>> instance. >> Yes, that is correct. Thinking more about this,

Re: Speeding up VMX with GDT fixmap trickery?

On 09/06/2017 02:13, Andy Lutomirski wrote: > Hi all- > > As promised when Thomas did his GDT fixmap work, here is a draft patch > to speed up KVM by extending it. > > The downside of this patch is that it makes the fixmap significantly > larger on 64-bit systems if NR_CPUS is large (it adds 15

Re: Speeding up VMX with GDT fixmap trickery?

On 09/06/2017 02:13, Andy Lutomirski wrote: > Hi all- > > As promised when Thomas did his GDT fixmap work, here is a draft patch > to speed up KVM by extending it. > > The downside of this patch is that it makes the fixmap significantly > larger on 64-bit systems if NR_CPUS is large (it adds 15

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 08/06/2017 22:17, Boris Ostrovsky wrote: > On 06/08/2017 05:02 PM, Tom Lendacky wrote: >> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: > What may be needed is making sure X86_FEATURE_SME is not set for PV > guests. And that may be something that Xen will need to control through

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 08/06/2017 22:17, Boris Ostrovsky wrote: > On 06/08/2017 05:02 PM, Tom Lendacky wrote: >> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: > What may be needed is making sure X86_FEATURE_SME is not set for PV > guests. And that may be something that Xen will need to control through

Re: [Xen-devel] [PATCH v2 1/2] doc, xen: document hypervisor sysfs nodes for xen

On 26/05/17 13:56, Juergen Gross wrote: > Today only a few sysfs nodes under /sys/hypervisor/ are documented > for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. > > Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new > file Documentation/ABI/stable/sysfs-hypervisor-xen and

Re: [Xen-devel] [PATCH v2 1/2] doc, xen: document hypervisor sysfs nodes for xen

On 26/05/17 13:56, Juergen Gross wrote: > Today only a few sysfs nodes under /sys/hypervisor/ are documented > for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. > > Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new > file Documentation/ABI/stable/sysfs-hypervisor-xen and

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

On 22/05/17 15:35, Boris Ostrovsky wrote: > On 05/22/2017 09:33 AM, Andrew Cooper wrote: >> On 22/05/17 09:57, Juergen Gross wrote: >>> Currently there is no reliable user interface inside a Xen guest to >>> determine its type (e.g. HVM, PV or PVH). Instead o

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

On 22/05/17 15:35, Boris Ostrovsky wrote: > On 05/22/2017 09:33 AM, Andrew Cooper wrote: >> On 22/05/17 09:57, Juergen Gross wrote: >>> Currently there is no reliable user interface inside a Xen guest to >>> determine its type (e.g. HVM, PV or PVH). Instead o

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

On 22/05/17 09:57, Juergen Gross wrote: > Currently there is no reliable user interface inside a Xen guest to > determine its type (e.g. HVM, PV or PVH). Instead of letting user mode > try to determine this by various rather hacky mechanisms (parsing of > boot messages before they are gone, trying

Re: [Xen-devel] [PATCH 2/2] xen: add sysfs node for guest type

On 22/05/17 09:57, Juergen Gross wrote: > Currently there is no reliable user interface inside a Xen guest to > determine its type (e.g. HVM, PV or PVH). Instead of letting user mode > try to determine this by various rather hacky mechanisms (parsing of > boot messages before they are gone, trying

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 14/05/17 00:17, PGNet Dev wrote: > On 5/13/17 3:15 PM, Valentin Vidic wrote: >> Try booting without 'hpet=force,verbose clocksource=hpet' and it should >> select xen by default: > Nope. Well, not quite ... > > With both > > 'hpet=force,verbose clocksource=hpet' > > removed, I end up with

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 14/05/17 00:17, PGNet Dev wrote: > On 5/13/17 3:15 PM, Valentin Vidic wrote: >> Try booting without 'hpet=force,verbose clocksource=hpet' and it should >> select xen by default: > Nope. Well, not quite ... > > With both > > 'hpet=force,verbose clocksource=hpet' > > removed, I end up with

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 21:05, PGNet Dev wrote: > On 5/13/17 12:59 PM, Andrew Cooper wrote: >> Ok. Lack of a clocksource is to be expected. >> >> The reason why the HPETs are unavailable is that dom0 is not a position >> to program them; dom0 doesn't know what Xen has set up in t

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 21:05, PGNet Dev wrote: > On 5/13/17 12:59 PM, Andrew Cooper wrote: >> Ok. Lack of a clocksource is to be expected. >> >> The reason why the HPETs are unavailable is that dom0 is not a position >> to program them; dom0 doesn't know what Xen has set up in t

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 20:28, Randy Dunlap wrote: > On 05/13/17 11:26, PGNet Dev wrote: >> On 5/13/17 10:41 AM, Randy Dunlap wrote: >>> [adding HPET driver maintainer] >> Thanks >> >>> A couple of comments below... In BIOS, HPET's enabled. >>> How about if you just boot Linux without Xen? Does HPET

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 20:28, Randy Dunlap wrote: > On 05/13/17 11:26, PGNet Dev wrote: >> On 5/13/17 10:41 AM, Randy Dunlap wrote: >>> [adding HPET driver maintainer] >> Thanks >> >>> A couple of comments below... In BIOS, HPET's enabled. >>> How about if you just boot Linux without Xen? Does HPET

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 20:49, PGNet Dev wrote: > On 5/13/17 12:38 PM, Andrew Cooper wrote: >> What is the issue here? >> >> Xen owns (and may use) any HPETs in the system. They are purposefully >> unavailable to even dom0. > The issue is that, when booting to Xen, hpet is not

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

On 13/05/2017 20:49, PGNet Dev wrote: > On 5/13/17 12:38 PM, Andrew Cooper wrote: >> What is the issue here? >> >> Xen owns (and may use) any HPETs in the system. They are purposefully >> unavailable to even dom0. > The issue is that, when booting to Xen, hpet is not

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > So the whole thing we're doing right now is

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > So the whole thing we're doing right now is

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 15:38, Juergen Gross wrote: > On 21/04/17 16:24, Boris Ostrovsky wrote: >>> +static bool __init xen_check_xsave(void) >>> { >>> - unsigned int ax, bx, cx, dx; >>> - unsigned int xsave_mask; >>> + unsigned int err, eax, edx; >>> >>> - ax = 1; >>> - cx = 0; >>> - cpuid(1,

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 15:38, Juergen Gross wrote: > On 21/04/17 16:24, Boris Ostrovsky wrote: >>> +static bool __init xen_check_xsave(void) >>> { >>> - unsigned int ax, bx, cx, dx; >>> - unsigned int xsave_mask; >>> + unsigned int err, eax, edx; >>> >>> - ax = 1; >>> - cx = 0; >>> - cpuid(1,

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

e reading this code in 6 months time. How about this: "Xen 4.0 and older accidentally leaked the host XSAVE flag into guest view, despite not being able to support guests using the functionality. Probe for the actual availability of XSAVE by seeing whether xgetbv executes successfully or raises #

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

e reading this code in 6 months time. How about this: "Xen 4.0 and older accidentally leaked the host XSAVE flag into guest view, despite not being able to support guests using the functionality. Probe for the actual availability of XSAVE by seeing whether xgetbv executes successfully or raises #

Re: [Xen-devel] [PATCH v2 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 13/04/17 11:11, Juergen Gross wrote: > @@ -281,22 +274,19 @@ static bool __init xen_check_mwait(void) > return false; > #endif > } > -static void __init xen_init_cpuid_mask(void) > + > +static bool __init xen_check_xsave(void) > { > - unsigned int ax, bx, cx, dx; > - unsigned

Re: [Xen-devel] [PATCH v2 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 13/04/17 11:11, Juergen Gross wrote: > @@ -281,22 +274,19 @@ static bool __init xen_check_mwait(void) > return false; > #endif > } > -static void __init xen_init_cpuid_mask(void) > + > +static bool __init xen_check_xsave(void) > { > - unsigned int ax, bx, cx, dx; > - unsigned

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

On 07/03/17 18:18, Boris Ostrovsky wrote: >>> Don't we need to pass vaddr down to all routines so that they select >>> appropriate tables? You seem to always be choosing the first one. >> IIUC, we clear whole page table subtree covered by one pgd entry. >> So, no, there's no need to pass vaddr

Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d

On 07/03/17 18:18, Boris Ostrovsky wrote: >>> Don't we need to pass vaddr down to all routines so that they select >>> appropriate tables? You seem to always be choosing the first one. >> IIUC, we clear whole page table subtree covered by one pgd entry. >> So, no, there's no need to pass vaddr

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 14/02/17 14:46, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: >>> It is the address of _time that will exceed the 32-bit limit. >> That seems extremely unlikely. That would mean we have more than 4G >> worth of

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 14/02/17 14:46, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: >>> It is the address of _time that will exceed the 32-bit limit. >> That seems extremely unlikely. That would mean we have more than 4G >> worth of

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 09/02/17 16:03, Jan Beulich wrote: On 09.02.17 at 16:56, wrote: >> On 09/02/17 15:50, Boris Ostrovsky wrote: >>> >>> On 02/09/2017 09:27 AM, Paul Durrant wrote: > -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] >

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 09/02/17 16:03, Jan Beulich wrote: On 09.02.17 at 16:56, wrote: >> On 09/02/17 15:50, Boris Ostrovsky wrote: >>> >>> On 02/09/2017 09:27 AM, Paul Durrant wrote: > -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 09 February 2017 14:18

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 09/02/17 15:50, Boris Ostrovsky wrote: > > > On 02/09/2017 09:27 AM, Paul Durrant wrote: >>> -Original Message- >>> From: Paul Durrant [mailto:paul.durr...@citrix.com] >>> Sent: 09 February 2017 14:18 >>> To: xen-de...@lists.xenproject.org; linux-kernel@vger.kernel.org >>> Cc: Paul

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 09/02/17 15:50, Boris Ostrovsky wrote: > > > On 02/09/2017 09:27 AM, Paul Durrant wrote: >>> -Original Message- >>> From: Paul Durrant [mailto:paul.durr...@citrix.com] >>> Sent: 09 February 2017 14:18 >>> To: xen-de...@lists.xenproject.org; linux-kernel@vger.kernel.org >>> Cc: Paul

Re: [Xen-devel] [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

On 03/02/17 16:40, Juergen Gross wrote: > On 03/02/17 17:20, Boris Ostrovsky wrote: + + __HEAD + +/* Entry point for PVH guests. */ >>> Could you add some comments about register conetnts at entry? >> Reference to Xen's docs/misc/hvmlite.markdown would be sifficient? > I think

Re: [Xen-devel] [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

On 03/02/17 16:40, Juergen Gross wrote: > On 03/02/17 17:20, Boris Ostrovsky wrote: + + __HEAD + +/* Entry point for PVH guests. */ >>> Could you add some comments about register conetnts at entry? >> Reference to Xen's docs/misc/hvmlite.markdown would be sifficient? > I think

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 16/12/2016 09:01, Borislav Petkov wrote: > @@ -91,6 +92,17 @@ static bool __init check_loader_disabled_bsp(void) > if (cmdline_find_option_bool(cmdline, option)) > *res = true; > > + if (!have_cpuid_p()) > + *res = true; > + > + a = 1; > + c = 0; >

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 16/12/2016 09:01, Borislav Petkov wrote: > @@ -91,6 +92,17 @@ static bool __init check_loader_disabled_bsp(void) > if (cmdline_find_option_bool(cmdline, option)) > *res = true; > > + if (!have_cpuid_p()) > + *res = true; > + > + a = 1; > + c = 0; >

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 16:53, Jan Beulich wrote: On 15.12.16 at 17:46, wrote: >> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >>> with today's kernel the system isn't coming up when booted as Xen dom0: >> Remind me again pls, is dom0 even supposed to load microcode?

Re: [Xen-devel] Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 16:53, Jan Beulich wrote: On 15.12.16 at 17:46, wrote: >> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote: >>> with today's kernel the system isn't coming up when booted as Xen dom0: >> Remind me again pls, is dom0 even supposed to load microcode? Isn't the >>

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:23, Andy Lutomirski wrote: > On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper <andrew.coop...@citrix.com> > wrote: >> On 02/12/16 17:07, Andy Lutomirski wrote: >>> On Dec 2, 2016 3:44 AM, "Andrew Cooper" <andrew.coop...@citrix.com> wrote: &g

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:23, Andy Lutomirski wrote: > On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper > wrote: >> On 02/12/16 17:07, Andy Lutomirski wrote: >>> On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: >>>> On 02/12/16 00:35, Andy Lutomirski wrote: >&g

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:07, Andy Lutomirski wrote: > On Dec 2, 2016 3:44 AM, "Andrew Cooper" <andrew.coop...@citrix.com> wrote: >> On 02/12/16 00:35, Andy Lutomirski wrote: >>> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't >>> guaranteed to serial

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:07, Andy Lutomirski wrote: > On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: >> On 02/12/16 00:35, Andy Lutomirski wrote: >>> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't >>> guaranteed to serialize. (Even CPUID isn't *really*

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

s and IRET-to-self is > ~110ns. But Xen PV will trap CPUID if possible, so IRET-to-self > should end up being a nice speedup. > > Cc: Andrew Cooper <andrew.coop...@citrix.com> > Signed-off-by: Andy Lutomirski <l...@kernel.org> CC'ing xen-devel and the Xen maintain

Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

s and IRET-to-self is > ~110ns. But Xen PV will trap CPUID if possible, so IRET-to-self > should end up being a nice speedup. > > Cc: Andrew Cooper > Signed-off-by: Andy Lutomirski CC'ing xen-devel and the Xen maintainers in Linux. As this is the only email from this series

Re: [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to serialize

On 01/12/16 17:08, Andy Lutomirski wrote: > On Thu, Dec 1, 2016 at 1:22 AM, Borislav Petkov wrote: >> On Wed, Nov 30, 2016 at 12:34:55PM -0800, Andy Lutomirski wrote: >>> Aside from being excessively slow, CPUID is problematic: Linux runs >>> on a handful of CPUs that don't have

Re: [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to serialize

On 01/12/16 17:08, Andy Lutomirski wrote: > On Thu, Dec 1, 2016 at 1:22 AM, Borislav Petkov wrote: >> On Wed, Nov 30, 2016 at 12:34:55PM -0800, Andy Lutomirski wrote: >>> Aside from being excessively slow, CPUID is problematic: Linux runs >>> on a handful of CPUs that don't have CPUID. MOV to

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

On 27/10/16 15:25, Boris Ostrovsky wrote: > > > On 10/14/2016 03:01 PM, Boris Ostrovsky wrote: >> On 10/14/2016 02:41 PM, Andrew Cooper wrote: >>> On 14/10/16 19:05, Boris Ostrovsky wrote: >>>> PVH guests don't receive ACPI hotplug interrupts and therefore &

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

On 27/10/16 15:25, Boris Ostrovsky wrote: > > > On 10/14/2016 03:01 PM, Boris Ostrovsky wrote: >> On 10/14/2016 02:41 PM, Andrew Cooper wrote: >>> On 14/10/16 19:05, Boris Ostrovsky wrote: >>>> PVH guests don't receive ACPI hotplug interrupts and therefore &

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 20/10/2016 10:14, Haozhong Zhang wrote: > > >> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to >> work >> and figure out what is on the DIMM, and which areas are safe to use. > I don't understand this ordering of events. Dom0 needs to have a > mapping

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 20/10/2016 10:14, Haozhong Zhang wrote: > > >> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to >> work >> and figure out what is on the DIMM, and which areas are safe to use. > I don't understand this ordering of events. Dom0 needs to have a > mapping

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

On 14/10/16 19:55, Boris Ostrovsky wrote: > On 10/14/2016 02:38 PM, Andrew Cooper wrote: >>> + jmp *%rax >>> + >>> +#else /* CONFIG_X86_64 */ >>> + >>> + call setup_pgtable_32 >>> + >>> + mov $_pa(initial_page_table), %eax

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

On 14/10/16 19:55, Boris Ostrovsky wrote: > On 10/14/2016 02:38 PM, Andrew Cooper wrote: >>> + jmp *%rax >>> + >>> +#else /* CONFIG_X86_64 */ >>> + >>> + call setup_pgtable_32 >>> + >>> + mov $_pa(initial_page_table), %eax

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

On 14/10/16 19:05, Boris Ostrovsky wrote: > PVH guests don't receive ACPI hotplug interrupts and therefore > need to monitor xenstore for CPU hotplug event. Why not? If they don't, they should. As we are providing ACPI anyway, we should provide all bits of it. ~Andrew

Re: [Xen-devel] [PATCH 8/8] xen/pvh: Enable CPU hotplug

On 14/10/16 19:05, Boris Ostrovsky wrote: > PVH guests don't receive ACPI hotplug interrupts and therefore > need to monitor xenstore for CPU hotplug event. Why not? If they don't, they should. As we are providing ACPI anyway, we should provide all bits of it. ~Andrew

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

On 14/10/16 19:05, Boris Ostrovsky wrote: > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S > new file mode 100644 > index 000..58c477b > --- /dev/null > +++ b/arch/x86/xen/xen-pvh.S > @@ -0,0 +1,143 @@ > +/* > + * Copyright C 2016, Oracle and/or its affiliates. All rights

Re: [Xen-devel] [PATCH 4/8] xen/pvh: Bootstrap PVH guest

On 14/10/16 19:05, Boris Ostrovsky wrote: > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S > new file mode 100644 > index 000..58c477b > --- /dev/null > +++ b/arch/x86/xen/xen-pvh.S > @@ -0,0 +1,143 @@ > +/* > + * Copyright C 2016, Oracle and/or its affiliates. All rights

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 14/10/16 08:08, Haozhong Zhang wrote: > On 10/13/16 20:33 +0100, Andrew Cooper wrote: >> On 13/10/16 19:59, Dan Williams wrote: >>> On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper >>> <andrew.coop...@citrix.com> wrote: >>>> On 13/10/16 16:40, Dan Wi

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 14/10/16 08:08, Haozhong Zhang wrote: > On 10/13/16 20:33 +0100, Andrew Cooper wrote: >> On 13/10/16 19:59, Dan Williams wrote: >>> On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper >>> wrote: >>>> On 13/10/16 16:40, Dan Williams wrote: >>>

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 13/10/16 19:59, Dan Williams wrote: > On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> On 13/10/16 16:40, Dan Williams wrote: >>> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich <jbeul...@suse.com> wrote: >>> [..] &

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 13/10/16 19:59, Dan Williams wrote: > On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper > wrote: >> On 13/10/16 16:40, Dan Williams wrote: >>> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: >>> [..] >>>>> I think we can do the similar for Xen, li

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 13/10/16 16:40, Dan Williams wrote: > On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: > [..] >>> I think we can do the similar for Xen, like to lay another pseudo >>> device on /dev/pmem and do the reservation, like 2. in my previous >>> reply. >> Well, my opinion

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 13/10/16 16:40, Dan Williams wrote: > On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: > [..] >>> I think we can do the similar for Xen, like to lay another pseudo >>> device on /dev/pmem and do the reservation, like 2. in my previous >>> reply. >> Well, my opinion certainly doesn't count

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 20:48, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote: >> On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk >> wrote: >>> On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams wrote: >> [..] Right, but

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 20:48, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote: >> On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk >> wrote: >>> On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams wrote: >> [..] Right, but why does the libnvdimm

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 06:52, Haozhong Zhang wrote: > On 10/10/16 17:43, Andrew Cooper wrote: >> On 10/10/16 01:35, Haozhong Zhang wrote: >>> Overview >>> >>> This RFC kernel patch series along with corresponding patch series of >>> Xen, QEMU and ndctl i

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 06:52, Haozhong Zhang wrote: > On 10/10/16 17:43, Andrew Cooper wrote: >> On 10/10/16 01:35, Haozhong Zhang wrote: >>> Overview >>> >>> This RFC kernel patch series along with corresponding patch series of >>> Xen, QEMU and ndctl i

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 18:51, Dan Williams wrote: > On Tue, Oct 11, 2016 at 9:58 AM, Konrad Rzeszutek Wilk > <konrad.w...@oracle.com> wrote: >> On Tue, Oct 11, 2016 at 08:53:33AM -0700, Dan Williams wrote: >>> On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich <jbeul...@suse.com

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 11/10/16 18:51, Dan Williams wrote: > On Tue, Oct 11, 2016 at 9:58 AM, Konrad Rzeszutek Wilk > wrote: >> On Tue, Oct 11, 2016 at 08:53:33AM -0700, Dan Williams wrote: >>> On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote: >>>>>>> Andrew Cooper 10

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 10/10/16 01:35, Haozhong Zhang wrote: > Overview > > This RFC kernel patch series along with corresponding patch series of > Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host > NVDIMM devices to Xen HVM domU as vNVDIMM devices. > > Xen hypervisor does not include an

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On 10/10/16 01:35, Haozhong Zhang wrote: > Overview > > This RFC kernel patch series along with corresponding patch series of > Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host > NVDIMM devices to Xen HVM domU as vNVDIMM devices. > > Xen hypervisor does not include an

Re: [PATCH] xen/x86: Update topology map for PV VCPUs

On 05/10/16 18:09, Boris Ostrovsky wrote: > Early during boot topology_update_package_map() computes > logical_pkg_ids for all present processors. > > Later, when processors are brought up, identify_cpu() updates > these values based on phys_pkg_id which is a function of > initial_apicid. On PV

Re: [PATCH] xen/x86: Update topology map for PV VCPUs

On 05/10/16 18:09, Boris Ostrovsky wrote: > Early during boot topology_update_package_map() computes > logical_pkg_ids for all present processors. > > Later, when processors are brought up, identify_cpu() updates > these values based on phys_pkg_id which is a function of > initial_apicid. On PV

<    1   2   3   4   5   6   >