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] [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 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] [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] 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 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 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] 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 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 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: [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 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: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] 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: [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] [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] [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 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 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 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 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 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 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 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] [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 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: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] 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 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: [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 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 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: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: [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 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: [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] [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 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] 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] [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: [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: [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 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] 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 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 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] 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 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 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: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: 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 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 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 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 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 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: [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: [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] xen: support 52 bit physical addresses in pv guests

On 21/09/17 17:00, Boris Ostrovsky wrote: Signed-off-by: Juergen Gross ---    arch/x86/include/asm/xen/page.h | 11 ++-    arch/x86/xen/mmu_pv.c   |  4 ++--    2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: #ifdef CONFIG_PARAVIRT +/* + * Paravirt alternatives are applied much earlier than normal alternatives. + * They

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

On 08/09/17 15:48, Juergen Gross wrote: > static void gnttab_request_version(void) > { > - int rc; > + long rc; > struct gnttab_set_version gsv; > > - gsv.version = 1; > + rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); This hypercall is information leak and

Re: [RFC 17/17] x86/traps: Use a new on_thread_stack() helper to clean up an assertion

On 12/09/2017 21:11, Josh Poimboeuf wrote: > On Wed, Sep 06, 2017 at 02:37:02PM -0700, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/include/asm/processor.h | 17 + >> arch/x86/include/asm/thread_info.h | 11 --- >>

Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping

On 27/09/17 15:56, Juergen Gross wrote: > On 27/09/17 16:48, Boris Ostrovsky wrote: >> On 09/27/2017 10:33 AM, Juergen Gross wrote: >>> On 27/09/17 15:38, Boris Ostrovsky wrote: On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a

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

On 04/09/17 13:41, Jan Beulich wrote: On 04.09.17 at 12:35, wrote: >> 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

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: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/11/17 19:34, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 29/11/17 14:47, Juergen Gross wrote: > On 29/11/17 15:44, Paolo Bonzini wrote: >> On 29/11/2017 15:25, Boris Ostrovsky wrote: >> zeropage is x86/Linux-specific so we'd need some sort of firmware (like >> grub) between a hypervisor and Linux to convert hvm_start_info to >>

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

On 09/05/18 11:21, Roger Pau Monne wrote: > On PVH MTRR is not initialized by the firmware (because there's no > firmware), so the kernel is started with MTRR disabled which means all > memory accesses are UC. > > So far there have been no issues (ie: slowdowns) caused by this > because PVH only

Re: [Xen-devel] [PATCH v2] xen: add new hypercall buffer mapping device

On 18/06/18 15:36, Juergen Gross wrote: > +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma) > +{ > + struct privcmd_buf_private *file_priv = file->private_data; > + struct privcmd_buf_vma_private *vma_priv; > + unsigned long count = vma_pages(vma); > +

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

On 07/06/18 11:21, Paul Durrant wrote: > Commit 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") > introduced a static checker warning: > > drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource() > warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()' > 64

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 02/05/18 16:09, Jan Beulich wrote: On 02.05.18 at 17:08, wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >> On 02.05.18 at 16:57, wrote: On 05/02/2018 04:05 AM, Jan Beulich wrote: On 30.04.18 at 18:23,

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 20:29, Sander Eikelenboom wrote: > On 26/10/17 19:49, Craig Bergstrom wrote: >> Sander, thanks for the details, they've been very useful. >> >> I suspect that your host system's mem=2048M parameter is causing the >> problem. Any chance you can confirm by removing the parameter and >>

Re: Avoid speculative indirect calls in kernel

On 04/01/2018 23:47, Tom Lendacky wrote: > On 1/4/2018 2:05 PM, David Woodhouse wrote: >> On Thu, 2018-01-04 at 14:00 -0600, Tom Lendacky wrote: >>> Yes, lfence is sufficient.  As long as the target is in the register >>> before the lfence and we jump through the register all is good, i.e.: >>

Re: [PATCH 0/7] IBRS patch series

On 04/01/18 19:33, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote: >> On Skylake the target for a 'ret' instruction may also come from the >> BTB. So if you ever let the RSB (which remembers where the 'call's came >> from get empty, you end up

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On 04/01/18 20:05, Greg KH wrote: > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: >> From: David Woodhouse >> >> We are impervious to the indirect branch prediction attack with retpoline >> but firmware won't be, so we still need to set IBRS to protect >> firmware

Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch

On 09/01/2018 00:58, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 4:44 PM, Andi Kleen wrote: >> Essentially the RSB are hidden registers, and the only way to clear them >> is the FILL_RETURN_BUFFER sequence. I don't see how clearing anything else >> would help? > Forget

Re: Avoid speculative indirect calls in kernel

On 04/01/18 15:32, Paolo Bonzini wrote: > On 04/01/2018 16:29, Woodhouse, David wrote: >> Adding that for KVM is in the Linux IBRS patch set that I've seen. >> Didn't we already have a conversation about how the Linux patch set >> does it as an atomically-switched MSR while you've done it manually

Re: [PATCH v3 10/13] x86/retpoline/pvops: Convert assembler indirect jumps

On 04/01/18 15:02, Juergen Gross wrote: > On 04/01/18 15:37, David Woodhouse wrote: >> Convert pvops invocations to use non-speculative call sequences, when >> CONFIG_RETPOLINE is enabled. >> >> There is scope for future optimisation here — once the pvops methods are >> actually set, we could just

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 08/01/18 10:08, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: > >> Commit-ID: 0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Gitweb: >> https://git.kernel.org/tip/0bf17c102177d5da9363bf8b1e4704b9996d5079 >> Author: Tom Lendacky >>

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On 08/01/18 10:42, Paul Turner wrote: > A sequence for efficiently refilling the RSB is: > mov $8, %rax; > .align 16; >3: call 4f; > 3p: pause; call 3p; > .align 16; > 4: call 5f; > 4p: pause; call 4p; > .align 16; >5: dec %rax; > jnz 3b; > add $(16*8),

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 11:49, David Woodhouse wrote: > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 372ba3f..40e6e54 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -904,6 +904,11 @@ static void __init early_identify_cpu(struct

Re: [PATCH v5 02/12] x86/retpoline: Add initial retpoline support

On 06/01/18 21:23, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Andrew Cooper wrote: >> On 06/01/18 11:49, David Woodhouse wrote: >>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>> index 372ba3f..40e6e54 100644 >>> --- a/arch/x86/ke

Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

On 08/01/18 14:47, Tom Lendacky wrote: > On 1/8/2018 5:10 AM, Thomas Gleixner wrote: >> On Mon, 8 Jan 2018, Andrew Cooper wrote: >> >>> On 08/01/18 10:08, Thomas Gleixner wrote: >>>> On Sat, 6 Jan 2018, tip-bot for Tom Lendacky wrote: >>>> >>&g

Re: Improve retpoline for Skylake

On 15/01/18 16:57, Andy Lutomirski wrote: > >> On Jan 15, 2018, at 12:26 AM, Jon Masters wrote: >> >>> On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: >>> On Fri, 12 Jan 2018, Andi Kleen wrote: > Skylake still loses if it takes an SMI, right? SMMs are

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On 17/01/18 09:02, Joerg Roedel wrote: > Hi Boris, > > thanks for testing this :) > > On Tue, Jan 16, 2018 at 09:47:06PM -0500, Boris Ostrovsky wrote: >> On 01/16/2018 11:36 AM, Joerg Roedel wrote: >>> +.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0 >> >> This (and next patch's

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 18/01/2018 23:25, Andy Lutomirski wrote: > On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli > wrote: >> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: >>> On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: On 18/01/2018 18:08, Dave

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On 21/01/2018 20:04, David Woodhouse wrote: > On Sun, 2018-01-21 at 19:37 +0000, Andrew Cooper wrote: >> It doesn't matter if an attacker can use SP1 to try and skip the IBPB. >> >> Exits to userspace/guest are serialising (with some retroactive updates >> to the ar

Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB

On 21/01/18 19:31, David Woodhouse wrote: > On Sun, 2018-01-21 at 20:01 +0100, Borislav Petkov wrote: >> so execution runs directly into the MSR write and the JMP is gone. >> >> So I don't see indirect branches anywhere... > Wait until the wind changes. > > Congratulations, you've just turned a

Re: [PATCH] x86/retpoline: Fill RSB on context switch for affected CPUs

On 12/01/18 17:49, David Woodhouse wrote: > When we context switch from a shallow call stack to a deeper one, as we > 'ret' up the deeper side we may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. This is > problematic if we have neither SMEP

Re: [PATCH] x86/xen: init %gs very early to avoid page faults with stack protector

On 01/02/18 12:16, Juergen Gross wrote: > When running as Xen pv guest %gs is initialized some time after > C code is started. Depending on stack protector usage this might be > too late, resulting in page faults. > > So setup %gs and MSR_GS_BASE in assembly code already. > > Cc:

Re: [Xen-devel] [PATCH] [v2] xen: hypercall: fix out-of-bounds memcpy

On 05/02/18 15:03, Arnd Bergmann wrote: Snipping deleted code to make things clearer: > + if (cmd > ARRAY_SIZE(physdevop_len)) > + return -ENOSYS; > > + len = physdevop_len[cmd]; > + memcpy(, arg, len); You'll want an array_nospec() or whatever its called these days. 

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/2018 21:09, Pavel Machek wrote: > On Fri 2018-02-09 17:47:43, Andy Lutomirski wrote: >> PCID bit set in CPUID should print a big fat warning like "WARNING: >> you are using 32-bit PTI on a 64-bit PCID-capable CPU. Your >> performance will increase dramatically if you switch to a 64-bit

Re: [PATCH 00/31 v2] PTI support for x86_32

On 09/02/18 13:35, Joerg Roedel wrote: > Hi Juergen, > > On Fri, Feb 09, 2018 at 01:11:42PM +0100, Juergen Gross wrote: >> On 09/02/18 10:25, Joerg Roedel wrote: >>> XENPV is also untested from my side, but I added checks to >>> not do the stack switches in the entry-code when XENPV is >>>

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On 16/02/2018 00:08, Linus Torvalds wrote: > On Thu, Feb 15, 2018 at 3:29 PM, Andy Lutomirski wrote: >> Linus, how would you feel about, by default, preventing 64-bit >> programs from long-jumping to __USER32_CS and vice versa? > How? It's a standard GDT entry. Are you going to

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:25, Nadav Amit wrote: > Dave Hansen wrote: > >> On 02/15/2018 08:35 AM, Nadav Amit wrote: >>> I removed the PTI disabling while SMEP is unsupported, although I >>> must admit I did not fully understand why it is required. >> Do you mean you don't

Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode

On 16/02/2018 00:51, Nadav Amit wrote: > Andrew Cooper <andrew.coop...@citrix.com> wrote: > >> On 16/02/2018 00:25, Nadav Amit wrote: >>> Dave Hansen <dave.han...@linux.intel.com> wrote: >>> >>>> On 02/15/2018 08:35 AM, Nadav Amit wrote: >&

Re: [Xen-devel] [PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()

On 02/01/18 14:24, Juergen Gross wrote: > On 02/01/18 15:18, Boris Ostrovsky wrote: >> On 12/23/2017 09:50 PM, Nick Desaulniers wrote: >>> The header declares this function as __init but is defined in __ref >>> section. >>> >>> Signed-off-by: Nick Desaulniers >> AFAIK

Re: Avoid speculative indirect calls in kernel

On 04/01/18 14:20, Paolo Bonzini wrote: > On 04/01/2018 12:47, Woodhouse, David wrote: >> On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote: No, really. The full mitigation with the microcode update and IBRS support is *slow*. Horribly slow. >>> What is IBRS? Invalidate BRanch

Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

On 23/01/18 18:45, Alan Cox wrote: > On Tue, 23 Jan 2018 16:52:55 + > David Woodhouse wrote: > >> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO >> bit set, they don't need KPTI either. > This is starting to get messy because we will eventually

<    1   2   3   4   5   6   >