Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 20:36, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> On 14/09/2016 20:23, Boris Ostrovsky wrote: >>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >>>> On Tue, Sep 13, 2016 at

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 20:36, Andy Lutomirski wrote: > On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper > wrote: >> On 14/09/2016 20:23, Boris Ostrovsky wrote: >>> On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >>>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 19:52, Andy Lutomirski wrote: > On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >>> You should explicitly check that, if the >>> feature is set under Xen PV, then the MSR actually

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 19:52, Andy Lutomirski wrote: > On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >>> You should explicitly check that, if the >>> feature is set under Xen PV, then the MSR actually works as >>> advertised. This may

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 20:23, Boris Ostrovsky wrote: > On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski >>> wrote: You should explicitly check that, if

Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction.

On 14/09/2016 20:23, Boris Ostrovsky wrote: > On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski >>> wrote: You should explicitly check that, if the feature is set under Xen PV, then

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

On 18/08/16 11:06, Jan Beulich wrote: On 17.08.16 at 22:32, wrote: >> One of the interesting things about XSA 154 fix ("x86: enforce consistent >> cachability of MMIO mappings") is that when certain applications (mcelog) >> are trying to map /dev/mmap and lurk in ISA

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

On 18/08/16 11:06, Jan Beulich wrote: On 17.08.16 at 22:32, wrote: >> One of the interesting things about XSA 154 fix ("x86: enforce consistent >> cachability of MMIO mappings") is that when certain applications (mcelog) >> are trying to map /dev/mmap and lurk in ISA regions - we get: > DYM

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 28/07/2016 00:46, Rafael J. Wysocki wrote: > On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote: >> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki >> wrote: >>> The STAO definition document: >>> >>>

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 28/07/2016 00:46, Rafael J. Wysocki wrote: > On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote: >> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki >> wrote: >>> The STAO definition document: >>> >>> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf >>>

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 27/07/16 19:42, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: >> Shannon Zhao (16): >> Xen: ACPI: Hide UART used by Xen > So this caused a trivial conflict. No biggie, it wasn't bad and the > patch was acked by Rafael. However, looking

Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0

On 27/07/16 19:42, Linus Torvalds wrote: > On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote: >> Shannon Zhao (16): >> Xen: ACPI: Hide UART used by Xen > So this caused a trivial conflict. No biggie, it wasn't bad and the > patch was acked by Rafael. However, looking at it made me

Re: [Xen-devel] [PATCH] xen-blkback: constify instance of "struct attribute_group"

On 07/07/16 10:45, Roger Pau Monne wrote: > On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote: >> The functions such get passed to have been taking pointers to const >> since at least 2.6.16. >> >> Signed-off-by: Jan Beulich > Acked-by: Roger Pau Monné

Re: [Xen-devel] [PATCH] xen-blkback: constify instance of "struct attribute_group"

On 07/07/16 10:45, Roger Pau Monne wrote: > On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote: >> The functions such get passed to have been taking pointers to const >> since at least 2.6.16. >> >> Signed-off-by: Jan Beulich > Acked-by: Roger Pau Monné > > Although the wording in the

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

On 29/06/16 13:16, Vitaly Kuznetsov wrote: > Andrew Cooper <andrew.coop...@citrix.com> writes: > >> On 28/06/16 17:47, Vitaly Kuznetsov wrote: >>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block >>> *self, unsigned long

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

On 29/06/16 13:16, Vitaly Kuznetsov wrote: > Andrew Cooper writes: > >> On 28/06/16 17:47, Vitaly Kuznetsov wrote: >>> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block >>> *self, unsigned long action, >>> int cpu = (long)hcpu;

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

On 28/06/16 17:47, Vitaly Kuznetsov wrote: > @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block > *self, unsigned long action, > int cpu = (long)hcpu; > switch (action) { > case CPU_UP_PREPARE: > + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

On 28/06/16 17:47, Vitaly Kuznetsov wrote: > @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block > *self, unsigned long action, > int cpu = (long)hcpu; > switch (action) { > case CPU_UP_PREPARE: > + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM

Re: [PATCH 1/7] x86/xen: Simplify set_aliased_prot

On 24/05/16 23:48, Andy Lutomirski wrote: > In aa1acff356bb ("x86/xen: Probe target addresses in > set_aliased_prot() before the hypercall"), I added an explicit probe > to work around a hypercall issue. The code can be simplified by > using probe_kernel_read. > > Cc

Re: [PATCH 1/7] x86/xen: Simplify set_aliased_prot

On 24/05/16 23:48, Andy Lutomirski wrote: > In aa1acff356bb ("x86/xen: Probe target addresses in > set_aliased_prot() before the hypercall"), I added an explicit probe > to work around a hypercall issue. The code can be simplified by > using probe_kernel_read. > > Cc

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/16 23:06, Andy Lutomirski wrote: > On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote: >> >> On 08/04/2016 18:00, Andy Lutomirski wrote: >>> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >>> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/16 23:06, Andy Lutomirski wrote: > On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote: >> >> On 08/04/2016 18:00, Andy Lutomirski wrote: >>> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >>> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on >>>

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/2016 01:24, Andy Lutomirski wrote: > I can't see any reason that we need the __KERNEL_DS segment at all -- > I think that everything that uses __KERNEL_DS could use __USER_DS > instead. Am I missing anything? This has been bugging me for a > while. > > I mulled over this a bit when

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/2016 01:24, Andy Lutomirski wrote: > I can't see any reason that we need the __KERNEL_DS segment at all -- > I think that everything that uses __KERNEL_DS could use __USER_DS > instead. Am I missing anything? This has been bugging me for a > while. > > I mulled over this a bit when

Re: [PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling

On 06/03/16 17:36, Andy Lutomirski wrote: > >> I haven't read the Xen hypervisor code, but what are those 5 words >> that were pushed on the stack by the hypervisor? It suspiciously is >> the size of an IRET frame. > I think it is nominally an IRET frame. It is a notminal IRET frame. Even to

Re: [PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling

On 06/03/16 17:36, Andy Lutomirski wrote: > >> I haven't read the Xen hypervisor code, but what are those 5 words >> that were pushed on the stack by the hypervisor? It suspiciously is >> the size of an IRET frame. > I think it is nominally an IRET frame. It is a notminal IRET frame. Even to

Re: [Xen-devel] [PATCH v2] xen/x86: Zero out .bss for PV guests

On 24/02/16 15:19, Boris Ostrovsky wrote: > Baremetal kernels clear .bss early in the boot but Xen PV guests don't > execute that code. They have been able to run without problems because > Xen domain builder happens to give out zeroed pages. However, since this > is not really guaranteed, .bss

Re: [Xen-devel] [PATCH v2] xen/x86: Zero out .bss for PV guests

On 24/02/16 15:19, Boris Ostrovsky wrote: > Baremetal kernels clear .bss early in the boot but Xen PV guests don't > execute that code. They have been able to run without problems because > Xen domain builder happens to give out zeroed pages. However, since this > is not really guaranteed, .bss

Re: [Xen-devel] [PATCH 1/2] hvc_xen: add earlycon support

On 24/02/16 17:18, Konrad Rzeszutek Wilk wrote: >> I could do the same here by dropping the if (!xen_pv_domain()) check >> above, but then if somebody specifies earlyprintk=xenboot on a non-Xen >> environment, I expect Linux would crash. > Nah, you made it "Work" with: > commit

Re: [Xen-devel] [PATCH 1/2] hvc_xen: add earlycon support

On 24/02/16 17:18, Konrad Rzeszutek Wilk wrote: >> I could do the same here by dropping the if (!xen_pv_domain()) check >> above, but then if somebody specifies earlyprintk=xenboot on a non-Xen >> environment, I expect Linux would crash. > Nah, you made it "Work" with: > commit

Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

On 24/02/16 14:12, David Vrabel wrote: > On 22/02/16 22:06, Boris Ostrovsky wrote: >> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't >> excecute that early code they should do it too. >> >> (Since we introduce macros for specifying 32- and 64-bit registers we >> can get

Re: [Xen-devel] [PATCH] xen/x86: Zero out .bss for PV guests

On 24/02/16 14:12, David Vrabel wrote: > On 22/02/16 22:06, Boris Ostrovsky wrote: >> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't >> excecute that early code they should do it too. >> >> (Since we introduce macros for specifying 32- and 64-bit registers we >> can get

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:45, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 04:38:40PM +0000, Andrew Cooper wrote: >> Does the early loader have extable support? If so, this is fairly easy >> to fix. If not, we have a problem. > It doesn't and regardless, you want to have this CPUID qu

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:35, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: >> I think we are OK for PV because this code will be executed after pvops are >> set and so we will be calling xen_cpuid(). > Not for the early loader - it is too early for pvops then. So

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:31, Boris Ostrovsky wrote: > > > On 02/08/2016 11:26 AM, Andrew Cooper wrote: >> On 08/02/16 16:12, Boris Ostrovsky wrote: >>> >>> On 02/08/2016 11:05 AM, Andrew Cooper wrote: >>>> For compatibility with other virtualisation s

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:12, Boris Ostrovsky wrote: > > > On 02/08/2016 11:05 AM, Andrew Cooper wrote: >> >> For compatibility with other virtualisation specs, Xen's cpuid leaves >> shift depending on configuration. >> >> Spec at >> http://xenbits.xen.org/gitwe

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 15:55, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote: >> It does. Very much IIRC, the problem was not caused by an access to MSR but >> rather some sort of address not being available somewhere. > See below. > >>> - microcode application on

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 15:55, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote: >> It does. Very much IIRC, the problem was not caused by an access to MSR but >> rather some sort of address not being available somewhere. > See below. > >>> - microcode application on

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:12, Boris Ostrovsky wrote: > > > On 02/08/2016 11:05 AM, Andrew Cooper wrote: >> >> For compatibility with other virtualisation specs, Xen's cpuid leaves >> shift depending on configuration. >> >> Spec at >> http://xenbits.xen.org/gitwe

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:31, Boris Ostrovsky wrote: > > > On 02/08/2016 11:26 AM, Andrew Cooper wrote: >> On 08/02/16 16:12, Boris Ostrovsky wrote: >>> >>> On 02/08/2016 11:05 AM, Andrew Cooper wrote: >>>> For compatibility with other virtualisation s

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:35, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote: >> I think we are OK for PV because this code will be executed after pvops are >> set and so we will be calling xen_cpuid(). > Not for the early loader - it is too early for pvops then. So

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 16:45, Borislav Petkov wrote: > On Mon, Feb 08, 2016 at 04:38:40PM +0000, Andrew Cooper wrote: >> Does the early loader have extable support? If so, this is fairly easy >> to fix. If not, we have a problem. > It doesn't and regardless, you want to have this CPUID qu

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On 03/02/2016 23:59, Luis R. Rodriguez wrote: > On Wed, Feb 03, 2016 at 08:52:50PM +0000, Andrew Cooper wrote: >> On 03/02/16 18:55, Luis R. Rodriguez wrote: >>> We add new hypervisor type to close the semantic gap for hypervisor types, >>> and >>> much lik

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On 03/02/16 18:55, Luis R. Rodriguez wrote: > We add new hypervisor type to close the semantic gap for hypervisor types, and > much like subarch enable also a subarch_data to let you pass and use your > hvmlite_start_info. This would not only help with the semantics but also help > avoid

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On 03/02/16 18:55, Luis R. Rodriguez wrote: > We add new hypervisor type to close the semantic gap for hypervisor types, and > much like subarch enable also a subarch_data to let you pass and use your > hvmlite_start_info. This would not only help with the semantics but also help > avoid

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

On 03/02/2016 23:59, Luis R. Rodriguez wrote: > On Wed, Feb 03, 2016 at 08:52:50PM +0000, Andrew Cooper wrote: >> On 03/02/16 18:55, Luis R. Rodriguez wrote: >>> We add new hypervisor type to close the semantic gap for hypervisor types, >>> and >>> much lik

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 23/01/2016 00:55, Luis R. Rodriguez wrote: > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper > wrote: >> the DMLite boot >> protocol is OS agnostic, and will be staying that way. > What's the DMLite boot protocol? It is a statement of the initial state

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 23/01/2016 00:55, Luis R. Rodriguez wrote: > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> the DMLite boot >> protocol is OS agnostic, and will be staying that way. > What's the DMLite boot protocol? It is a statement of th

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 22/01/2016 23:32, Luis R. Rodriguez wrote: > On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote: >> +/* >> + * See Documentation/x86/boot.txt. >> + * >> + * Version 2.12 supports Xen entry point but we will use default x86/PC >> + * environment (i.e.

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

On 22/01/2016 23:32, Luis R. Rodriguez wrote: > On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote: >> +/* >> + * See Documentation/x86/boot.txt. >> + * >> + * Version 2.12 supports Xen entry point but we will use default x86/PC >> + * environment (i.e.

Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

On 20/12/15 09:25, Michael S. Tsirkin wrote: > On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote: >> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote: >>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: You could of course go fix that instead of

Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)

On 20/12/15 09:25, Michael S. Tsirkin wrote: > On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote: >> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote: >>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: You could of course go fix that instead of

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On 19/11/15 22:07, Andy Lutomirski wrote: > On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky > wrote: >> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike >> the >> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit >> (and sysret32 in compat

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

On 19/11/15 22:07, Andy Lutomirski wrote: > On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky > wrote: >> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike >> the >> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 13:41, Andrew Cooper wrote: > On 24/11/15 13:39, Jan Beulich wrote: >>>>> On 24.11.15 at 13:57, wrote: >>> V Tue, 24 Nov 2015 10:35:03 + >>> Andrew Cooper napsáno: >>> >>>> On 24/11/15 10:17, Petr Tesarik wrote: >>&

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 13:39, Jan Beulich wrote: >>>> On 24.11.15 at 13:57, wrote: >> V Tue, 24 Nov 2015 10:35:03 +0000 >> Andrew Cooper napsáno: >> >>> On 24/11/15 10:17, Petr Tesarik wrote: >>>> On Tue, 24 Nov 2015 10:09:01 + >>>> Davi

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 10:17, Petr Tesarik wrote: > On Tue, 24 Nov 2015 10:09:01 + > David Vrabel wrote: > >> On 24/11/15 09:55, Malcolm Crossley wrote: >>> On 24/11/15 08:59, Jan Beulich wrote: >>> On 24.11.15 at 07:55, wrote: > What about: > > 4) Instead of relying on the kernel

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 10:17, Petr Tesarik wrote: > On Tue, 24 Nov 2015 10:09:01 + > David Vrabel wrote: > >> On 24/11/15 09:55, Malcolm Crossley wrote: >>> On 24/11/15 08:59, Jan Beulich wrote: >>> On 24.11.15 at 07:55, wrote: > What about: > >

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 13:41, Andrew Cooper wrote: > On 24/11/15 13:39, Jan Beulich wrote: >>>>> On 24.11.15 at 13:57, <ptesa...@suse.cz> wrote: >>> V Tue, 24 Nov 2015 10:35:03 + >>> Andrew Cooper <andrew.coop...@citrix.com> napsáno: >>> >>

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

On 24/11/15 13:39, Jan Beulich wrote: >>>> On 24.11.15 at 13:57, <ptesa...@suse.cz> wrote: >> V Tue, 24 Nov 2015 10:35:03 + >> Andrew Cooper <andrew.coop...@citrix.com> napsáno: >> >>> On 24/11/15 10:17, Petr Tesarik wrote: >>>>

[tip:x86/urgent] x86/cpu: Fix SMAP check in PVOPS environments

Commit-ID: 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Gitweb: http://git.kernel.org/tip/581b7f158fe0383b492acd1ce3fb4e99d4e57808 Author: Andrew Cooper AuthorDate: Wed, 3 Jun 2015 10:31:14 +0100 Committer: Thomas Gleixner CommitDate: Thu, 19 Nov 2015 11:07:49 +0100 x86/cpu: Fix SMAP

[tip:x86/urgent] x86/cpu: Fix SMAP check in PVOPS environments

Commit-ID: 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Gitweb: http://git.kernel.org/tip/581b7f158fe0383b492acd1ce3fb4e99d4e57808 Author: Andrew Cooper <andrew.coop...@citrix.com> AuthorDate: Wed, 3 Jun 2015 10:31:14 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitD

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 17/11/15 19:16, Andy Lutomirski wrote: > On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper > wrote: >> On 17/11/15 18:49, Andy Lutomirski wrote: >>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" >>> wrote: >>>> On 11/16/2015 04:55 PM, H. Peter A

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 17/11/15 18:49, Andy Lutomirski wrote: > On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote: >> On 11/16/2015 04:55 PM, H. Peter Anvin wrote: >>> On 11/16/15 12:22, Borislav Petkov wrote: Huh, so what's wrong with a jump: jmp 1f swapgs 1: >>>

Re: [PATCH] x86/cpu: Fix SMAP check in PVOPS environments

Ping? None of the discussion on this thread altered the contents of this patch, and the bug is still present. ~Andrew On 03/06/15 10:31, Andrew Cooper wrote: > There appears to be no formal statement of what pv_irq_ops.save_fl() is > supposed to return precisely. Native returns the full

Re: [PATCH] x86/cpu: Fix SMAP check in PVOPS environments

Ping? None of the discussion on this thread altered the contents of this patch, and the bug is still present. ~Andrew On 03/06/15 10:31, Andrew Cooper wrote: > There appears to be no formal statement of what pv_irq_ops.save_fl() is > supposed to return precisely. Native returns the full

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 17/11/15 18:49, Andy Lutomirski wrote: > On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote: >> On 11/16/2015 04:55 PM, H. Peter Anvin wrote: >>> On 11/16/15 12:22, Borislav Petkov wrote: Huh, so what's wrong with a jump: jmp 1f

Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit

On 17/11/15 19:16, Andy Lutomirski wrote: > On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper > <andrew.coop...@citrix.com> wrote: >> On 17/11/15 18:49, Andy Lutomirski wrote: >>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" <boris.ostrov...@oracle.com>

Re: [Xen-devel] [RFC PATCH] Use vAPIC when doing IPI for PVHVM guests.

On 08/10/15 06:05, Juergen Gross wrote: > On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote: >> Hey, >> >> I was running some tools in which we would heavily do rescheduling >> of events - and realized to my surprise that the event channels (and >> the hypercall) would slow things down. If I

Re: [Xen-devel] [RFC PATCH] Use vAPIC when doing IPI for PVHVM guests.

On 08/10/15 06:05, Juergen Gross wrote: > On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote: >> Hey, >> >> I was running some tools in which we would heavily do rescheduling >> of events - and realized to my surprise that the event channels (and >> the hypercall) would slow things down. If I

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 16:27, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote: >> That's not a big deal, that's what *_safe is for. The problem is that >> there are definitely some cases where the *_safe version is not being used. > I mean to do feature checks which

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 00:33, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over bugs. In particular, KVM

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 00:33, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over bugs. In particular, KVM

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 16:27, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote: >> That's not a big deal, that's what *_safe is for. The problem is that >> there are definitely some cases where the *_safe version is not being used. > I mean to do feature checks which

Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option

On 31/07/15 14:44, Boris Ostrovsky wrote: > On 07/31/2015 05:10 AM, Andrew Cooper wrote: >> On 30/07/15 22:31, Andy Lutomirski wrote: >>> This is intended for x86/urgent. Sorry for taking so long, but it >>> seemed nice to avoid breaking Xen. >> Very much apprec

Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 22:31, Andy Lutomirski wrote: > This is intended for x86/urgent. Sorry for taking so long, but it > seemed nice to avoid breaking Xen. Very much appreciated. Thanks! > > This fixes the "dazed and confused" issue which was exposed by the > CVE-2015-5157 fix. It's also probably a

Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option

On 31/07/15 14:44, Boris Ostrovsky wrote: On 07/31/2015 05:10 AM, Andrew Cooper wrote: On 30/07/15 22:31, Andy Lutomirski wrote: This is intended for x86/urgent. Sorry for taking so long, but it seemed nice to avoid breaking Xen. Very much appreciated. Thanks! This fixes the dazed

Re: [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 22:31, Andy Lutomirski wrote: This is intended for x86/urgent. Sorry for taking so long, but it seemed nice to avoid breaking Xen. Very much appreciated. Thanks! This fixes the dazed and confused issue which was exposed by the CVE-2015-5157 fix. It's also probably a good

Re: [PATCH v6 2/4] x86/ldt: Make modify_ldt synchronous

On 30/07/2015 22:31, Andy Lutomirski wrote: > Note to -stable maintainers: by itself, this patch makes a > pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest, > the new ldt_gdt selftest is likely to OOPS. Even without this > patch, the test can OOPS, but it's much less likely to

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 30/07/15 19:30, Andy Lutomirski wrote: > On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper > wrote: >> On 30/07/2015 00:13, Andy Lutomirski wrote: >>> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper >>> wrote: >>>> On 29/07/2015 23:49, Boris Ostrovsky

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 17:31, Boris Ostrovsky wrote: > On 07/30/2015 12:12 PM, Andrew Cooper wrote: >> On 30/07/15 17:05, Borislav Petkov wrote: >>> On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote: >>>> As far as Xen guests are concerned, >>>>

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 17:05, Borislav Petkov wrote: > On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote: >> As far as Xen guests are concerned, >> >> Tested-by: Boris Ostrovsky > Does that mean, this patch 1/4 fixes the 32bit issue you guys are still > debugging on the v4 thread? Or does that

Re: [PATCH v6 2/4] x86/ldt: Make modify_ldt synchronous

On 30/07/2015 22:31, Andy Lutomirski wrote: Note to -stable maintainers: by itself, this patch makes a pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest, the new ldt_gdt selftest is likely to OOPS. Even without this patch, the test can OOPS, but it's much less likely to

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 30/07/15 19:30, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 30/07/2015 00:13, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 29/07/2015 23:49, Boris Ostrovsky wrote

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 17:31, Boris Ostrovsky wrote: On 07/30/2015 12:12 PM, Andrew Cooper wrote: On 30/07/15 17:05, Borislav Petkov wrote: On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote: As far as Xen guests are concerned, Tested-by: Boris Ostrovsky boris.ostrov...@oracle.com Does

Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option

On 30/07/15 17:05, Borislav Petkov wrote: On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote: As far as Xen guests are concerned, Tested-by: Boris Ostrovsky boris.ostrov...@oracle.com Does that mean, this patch 1/4 fixes the 32bit issue you guys are still debugging on the v4

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 30/07/2015 00:13, Andy Lutomirski wrote: > On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper > wrote: >> On 29/07/2015 23:49, Boris Ostrovsky wrote: >>> On 07/29/2015 06:46 PM, David Vrabel wrote: >>>> On 29/07/2015 23:11, Andrew Cooper wrote: >>>>

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 23:49, Boris Ostrovsky wrote: > On 07/29/2015 06:46 PM, David Vrabel wrote: >> >> On 29/07/2015 23:11, Andrew Cooper wrote: >>> On 29/07/2015 23:05, Andy Lutomirski wrote: >>>> On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper >>>> w

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 23:05, Andy Lutomirski wrote: > On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper > wrote: >> On 29/07/2015 22:26, Andy Lutomirski wrote: >>> On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky >>> wrote: >>>> On 07/29/2015 03:03 PM, Andrew Co

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 22:26, Andy Lutomirski wrote: > On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky > wrote: >> On 07/29/2015 03:03 PM, Andrew Cooper wrote: >>> On 29/07/15 15:43, Boris Ostrovsky wrote: >>>> FYI, I have got a repro now and am investigating. >>>

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/15 15:43, Boris Ostrovsky wrote: > FYI, I have got a repro now and am investigating. Good and bad news. This bug has nothing to do with LDTs themselves. I have worked out what is going on, but this: diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/15 06:28, Andy Lutomirski wrote: > On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky > wrote: >> On 07/28/2015 08:47 PM, Andrew Cooper wrote: >>> On 29/07/2015 01:21, Andy Lutomirski wrote: >>>> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky >>

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 23:05, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 29/07/2015 22:26, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky boris.ostrov...@oracle.com wrote: On 07/29/2015 03:03 PM, Andrew Cooper

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 22:26, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky boris.ostrov...@oracle.com wrote: On 07/29/2015 03:03 PM, Andrew Cooper wrote: On 29/07/15 15:43, Boris Ostrovsky wrote: FYI, I have got a repro now and am investigating. Good and bad news. This bug

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/15 15:43, Boris Ostrovsky wrote: FYI, I have got a repro now and am investigating. Good and bad news. This bug has nothing to do with LDTs themselves. I have worked out what is going on, but this: diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 5abeaac..7e1a82e

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 30/07/2015 00:13, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 29/07/2015 23:49, Boris Ostrovsky wrote: On 07/29/2015 06:46 PM, David Vrabel wrote: On 29/07/2015 23:11, Andrew Cooper wrote: On 29/07/2015 23:05, Andy Lutomirski

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 23:49, Boris Ostrovsky wrote: On 07/29/2015 06:46 PM, David Vrabel wrote: On 29/07/2015 23:11, Andrew Cooper wrote: On 29/07/2015 23:05, Andy Lutomirski wrote: On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper andrew.coop...@citrix.com wrote: On 29/07/2015 22:26, Andy Lutomirski

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/15 06:28, Andy Lutomirski wrote: On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky boris.ostrov...@oracle.com wrote: On 07/28/2015 08:47 PM, Andrew Cooper wrote: On 29/07/2015 01:21, Andy Lutomirski wrote: On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky boris.ostrov...@oracle.com

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

On 29/07/2015 01:21, Andy Lutomirski wrote: > On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky > wrote: >> On 07/28/2015 01:07 PM, Andy Lutomirski wrote: >>> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper >>> wrote: >>>> I suspect that the set_l

Re: [Xen-devel] [PATCH 0/8] Use correctly the Xen memory terminologies in Linux

On 28/07/15 22:06, H. Peter Anvin wrote: > On 07/28/2015 08:02 AM, Julien Grall wrote: >> Hi all, >> >> This patch series aims to use the memory terminologies described in >> include/linux/mm.h [1] for Linux xen code. >> >> Linux is using mistakenly MFN when GFN is meant, I suspect this is because

<    1   2   3   4   5   6   >