[Xen-devel] [libvirt test] 104021: regressions - FAIL

flight 104021 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/104021/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 9 debian-di-installfail REGR. vs. 104005 Regressions which are

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

First of all, thank you for comments On 01/04/2017 03:03 AM, Stefano Stabellini wrote: On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko ---

Re: [Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

On 01/03/2017 09:21 AM, Laura Abbott wrote: > Happy New Year! > > This is a very minor rebase from v5. It only moves a few headers around. > I think this series should be ready to be queued up for 4.11. FWIW: Tested-by: Florian Fainelli How do we get this series

[Xen-devel] [xen-unstable test] 104015: tolerable FAIL - PUSHED

flight 104015 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104015/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104004

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

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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

On January 03, 2017 4:23 PM, Jan Beulich wrote: On 03.01.17 at 09:15, wrote: > >> >>>-Original Message- >>>From: Jan Beulich [mailto:jbeul...@suse.com] >>>Sent: Tuesday, January 03, 2017 3:35 PM >>>To: Xuquan (Quan Xu) >>>Cc: Andrew Cooper; George Dunlap;

Re: [Xen-devel] (no subject)

On Wed, 28 Dec 2016, Ronald Rojas wrote: > The first 57 commits are merged from previous work done by > George Dunlap at (https://github.com/gwd/schedbench) and > implement manipulating Cpu pool. The last 2 commits merge > his work onto the Xen tree and implement finding system > information

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > xen/include/public/io/kbdif.h | 64 > +++ > 1 file

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Thu, 29 Dec 2016, Julien Grall wrote: > Hi all, > > The document below is an early version of a design > proposal for PCI Passthrough in Xen. It aims to > describe from an high level perspective the interaction > with the different subsystems and how guest will be able > to discover and access

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

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

Re: [Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > Always take the vgic lock of the old vcpu. When more than one irq > > migration is requested before the first one completes, take the vgic > > lock of the oldest vcpu. > > > > Write the

[Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

Always set the new physical irq affinity at the beginning of vgic_migrate_irq, in all cases. No need to set physical irq affinity in gic_update_one_lr anymore, solving the lock inversion problem. After migrating an interrupt from vcpu/pcpu 0 to vcpu/pcpu 1, it is possible to receive a physical

Re: [Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

On 01/03/2017 02:56 PM, Florian Fainelli wrote: > On 01/03/2017 09:21 AM, Laura Abbott wrote: >> Happy New Year! >> >> This is a very minor rebase from v5. It only moves a few headers around. >> I think this series should be ready to be queued up for 4.11. > > FWIW: > > Tested-by: Florian

Re: [Xen-devel] [PATCH v2 1/4] xen/arm: fix GIC_INVALID_LR

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > GIC_INVALID_LR should be 0xff, but actually, defined as ~(uint8_t)0, is > > 0x. Fix the problem by placing the ~ operator before the cast. > > > > Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > gic_update_one_lr is called with the vgic lock held, but it calls > > vgic_get_target_vcpu, which tries to obtain the rank lock. This can > > cause deadlocks. > > > > We already have a

Re: [Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

On 01/03/2017 12:53 PM, Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Boris Ostrovsky > CC: Suravee Suthikulpanit Reviewed-by:

Re: [Xen-devel] Future support of 5-level paging in Xen

On 01/03/2017 12:32 PM, anshul makkar wrote: > > > On 08/12/16 23:40, Boris Ostrovsky wrote: >> >> >> On 12/08/2016 05:21 PM, Andrew Cooper wrote: >>> On 08/12/2016 19:18, Stefano Stabellini wrote: >> >>> Of course even the largest virtual machine today (2TB on Amazon AFAIK) is not close

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

On 12/23/2016 05:51 AM, Roger Pau Monné wrote: > Hello, > > I've been looking into the STAO specification[0], because I think it would > also > be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to > use it. > > Xen doesn't have an AML parser, so I'm not sure how is it

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under include/uapi/

Re: [Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

On Thu, Dec 22, 2016 at 04:08:22PM +0200, Andy Shevchenko wrote: > On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote: > > Move the __jump_table from the a custom section solution > > to a generic solution, this avoiding extra vmlinux.lds.h > > customizations. > > > > This also demos the

Re: [Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

On Thu, Dec 22, 2016 at 03:58:18PM +0200, Andy Shevchenko wrote: > On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote: > > +#define LINKTABLE_FOR_EACH(pointer, tbl) > > Hmm... SOMEONE LIKES CAPITAL LETTERS FOR everything, right? :-) > > I would expect more

Re: [Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

> diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c > new file mode 100644 > index 000..04901c1 > --- /dev/null > +++ b/xen/arch/x86/hvm/acpi.c > @@ -0,0 +1,24 @@ > +/* acpi.c: ACPI access handling > + * > + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

On 01/03/2017 01:19 PM, Stefano Stabellini wrote: > On Tue, 3 Jan 2017, Boris Ostrovsky wrote: >> Signed-off-by: Boris Ostrovsky >> Reviewed-by: Konrad Rzeszutek Wilk >> --- >> CC: George Dunlap >> CC: Konrad

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Thu, 29 Dec 2016, Bhupinder Thakur wrote: > On 28 December 2016 at 23:19, Julien Grall wrote: > > On 21/12/16 22:12, Stefano Stabellini wrote: > >> > >> On Wed, 21 Dec 2016, Julien Grall wrote: > >>> > >>> On 20/12/2016 20:53, Stefano Stabellini wrote: > > On

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

On 01/03/2017 06:28 PM, Jan Beulich wrote: On 03.01.17 at 16:39, wrote: --- a/xen/include/public/io/kbdif.h +++ b/xen/include/public/io/kbdif.h @@ -45,6 +45,19 @@ */ #define XENKBD_TYPE_POS 4 +/* + * Multi-touch event + * Capable backend sets

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 21/12/16 22:12, Stefano Stabellini wrote: > > On Wed, 21 Dec 2016, Julien Grall wrote: > > > On 20/12/2016 20:53, Stefano Stabellini wrote: > > > > On Tue, 20 Dec 2016, Julien Grall wrote: > > > > > On 19/12/2016 21:24, Stefano

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

On 01/03/2017 11:58 AM, Jan Beulich wrote: On 03.01.17 at 15:04, wrote: >> --- a/docs/misc/hvmlite.markdown >> +++ b/docs/misc/hvmlite.markdown >> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field >> rsdp_paddr). >> >> Description of

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

On Wed, 28 Dec 2016, Julien Grall wrote: > (CC Andrew and Jan) > > Hi Stefano, > > On 20/12/16 22:33, Stefano Stabellini wrote: > > On Tue, 20 Dec 2016, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 20/12/2016 00:54, Stefano Stabellini wrote: > > > > On Mon, 19 Dec 2016, Julien Grall

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

flight 104008 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104008/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-bootfail REGR. vs. 104004

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

> We can provide a crafted MADT that reflects the number of vCPUs available to > Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace > and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU > hotplug we would need to use the hypercall interface as it's

Re: [Xen-devel] Xen: Support for mapping OperationRegion in ACPI ASL

On Thu, 22 Dec 2016, Jan Beulich wrote: > >>> On 20.12.16 at 23:50, wrote: > > On Tue, 20 Dec 2016, Jan Beulich wrote: > >> >>> On 20.12.16 at 00:01, wrote: > >> > This is actually not an ARM specific question, so changing the subject > >> > and

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

On Fri, 23 Dec 2016, Roger Pau Monné wrote: > Hello, > > I've been looking into the STAO specification[0], because I think it would > also > be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to > use it. > > Xen doesn't have an AML parser, so I'm not sure how is it

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

On 12/19/2016 11:03 PM, Doug Goldstein wrote: On 12/19/16 10:02 AM, Doug Goldstein wrote: On 12/14/16 3:09 PM, Daniel De Graaf wrote: On 12/12/2016 09:00 AM, Anshul Makkar wrote: During guest migrate allow permission to prevent spurious page faults. Prevents these errors: d73: Non-privileged

Re: [Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

On 01/03/2017 09:04 AM, Boris Ostrovsky wrote: This domctl will allow toolstack to read and write some ACPI registers. It will be available to both x86 and ARM but will be implemented first only for x86 Signed-off-by: Boris Ostrovsky Acked-by: Daniel De Graaf

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

On 3 January 2017 at 17:50, Al Stone wrote: > On 12/23/2016 05:51 AM, Roger Pau Monné wrote: >> Hello, >> >> I've been looking into the STAO specification[0], because I think it would >> also >> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to >>

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

On Tue, 3 Jan 2017, Boris Ostrovsky wrote: > Signed-off-by: Boris Ostrovsky > Reviewed-by: Konrad Rzeszutek Wilk > --- > CC: George Dunlap > CC: Konrad Rzeszutek Wilk > CC: Stefano

Re: [Xen-devel] [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

On Mon, 2 Jan 2017, Juergen Gross wrote: > On 28/12/16 01:47, Jiandi An wrote: > > Ensure all reserved fields of xatp are zero before making > > hypervisor call to XEN in xen_map_device_mmio(). > > xenmem_add_to_physmap_one() in XEN fails the mapping request if > > extra.res reserved field in xatp

Re: [Xen-devel] [RFC] Xen PV Drivers Lifecycle

On Wed, 28 Dec 2016, George Dunlap wrote: > On Tue, Dec 20, 2016 at 11:09 PM, Stefano Stabellini > wrote: > > On Tue, 20 Dec 2016, Jan Beulich wrote: > >> >>> On 20.12.16 at 01:47, wrote: > >> > ## Design Phase > >> > > >> > The first step toward

[Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Boris Ostrovsky CC: Suravee Suthikulpanit --- xen/arch/x86/hvm/svm/svm.c | 2 +- 1 file changed, 1 insertion(+),

Re: [Xen-devel] [PATCH RFC 59/59] tools/xenlight: Create interface for xenlight info

On Thu, Dec 29, 2016 at 01:45:54PM +, George Dunlap wrote: > Hey Ronald! Looks like you're getting going pretty well here. > > At a high level: I think I began by saying that this would probably all > be a single patch. But I think it would probably be easier to review > the different

Re: [Xen-devel] [PATCH v3 0/5] boot-wrapper: arm64: Xen support

On Thu, Dec 15, 2016 at 12:27:13PM +, Andre Przywara wrote: > These patches allow to include a Xen hypervisor binary into a boot-wrapper > ELF file, so that a Foundation Platform or a Fast Model can boot a Xen > system (including a Dom0 kernel). Thanks! I've applied the series and pushed it

Re: [Xen-devel] Future support of 5-level paging in Xen

On 08/12/16 23:40, Boris Ostrovsky wrote: On 12/08/2016 05:21 PM, Andrew Cooper wrote: On 08/12/2016 19:18, Stefano Stabellini wrote: Of course even the largest virtual machine today (2TB on Amazon AFAIK) is not close to reaching the current memory limit, but it's just a matter of

Re: [Xen-devel] [PATCH v3 4/5] Xen: Select correct dom0 console

On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote: > From: Ian Campbell > > If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to > the usual ttyAMA0 otherwise. > > Signed-off-by: Ian Campbell > Signed-off-by:

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

On 03/01/17 16:19, Jan Beulich wrote: On 03.01.17 at 16:22, wrote: >> On 03/01/17 13:10, Jan Beulich wrote: >>> --- a/xen/arch/x86/hvm/emulate.c >>> +++ b/xen/arch/x86/hvm/emulate.c >>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg( >>> return

[Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

Happy New Year! This is a very minor rebase from v5. It only moves a few headers around. I think this series should be ready to be queued up for 4.11. Thanks, Laura Laura Abbott (11): lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL mm/cma: Cleanup highmem check arm64: Move some macros under

[Xen-devel] [ovmf baseline-only test] 68310: all pass

This run is configured for baseline tests only. flight 68310 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68310/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7 baseline

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

>>> On 03.01.17 at 15:04, wrote: > --- a/docs/misc/hvmlite.markdown > +++ b/docs/misc/hvmlite.markdown > @@ -75,3 +75,14 @@ info structure that's passed at boot time (field > rsdp_paddr). > > Description of paravirtualized devices will come from XenStore, just as

Re: [Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

>>> On 03.01.17 at 15:04, wrote: > Noone else needs to include it since it is only useful to code > that can made domctl calls. And public domctl.h can only be included > by the toolstack or the hypervisor. > > Signed-off-by: Boris Ostrovsky

[Xen-devel] [distros-debian-snapshot test] 68308: tolerable FAIL

flight 68308 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68308/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 68277

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

>>> On 03.01.17 at 16:39, wrote: > --- a/xen/include/public/io/kbdif.h > +++ b/xen/include/public/io/kbdif.h > @@ -45,6 +45,19 @@ > */ > #define XENKBD_TYPE_POS 4 > > +/* > + * Multi-touch event > + * Capable backend sets feature-multi-touch in xenstore. > + *

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

>>> On 03.01.17 at 16:22, wrote: > On 03/01/17 13:10, Jan Beulich wrote: >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg( >> return hvmemul_write(seg, offset, p_new, bytes, ctxt); >> } >>

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

On 03/01/17 16:01, Boris Ostrovsky wrote: >> >> +static void avic_dump(unsigned char ch) >> +{ >> +struct domain *d; >> +struct vcpu *v; >> + >> +printk("*** SVM AVIC Statistics **\n"); >> + >> +rcu_read_lock(_read_lock); >> + >> +for_each_domain ( d ) >>

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

> > +static void avic_dump(unsigned char ch) > +{ > +struct domain *d; > +struct vcpu *v; > + > +printk("*** SVM AVIC Statistics **\n"); > + > +rcu_read_lock(_read_lock); > + > +for_each_domain ( d ) > +{ > +if ( !is_hvm_domain(d) ) ||

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

From: Nicolas Dichtel Date: Tue, 3 Jan 2017 15:35:44 +0100 > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On Fri, Dec 23, 2016 at 12:13:47PM -0500, Boris Ostrovsky wrote: > On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote: > > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote: > >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote: > But this still assumes that dom0 handles

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

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

Re: [Xen-devel] [PATCH v2 07/10] x86/SVM: Add vcpu scheduling support for AVIC

On 12/31/2016 12:45 AM, Suravee Suthikulpanit wrote: > Add hooks to manage AVIC data structure during vcpu scheduling. > > Signed-off-by: Suravee Suthikulpanit > Cc: Konrad Rzeszutek Wilk > Cc: Jan Beulich > Cc: Boris

[Xen-devel] [RFC] kbdif: add multi-touch support

From: Oleksandr Andrushchenko Hi, all! I am working on adding multi-touch support to the existing kbdif protocol and would like to request for comments on the below patch. The aim is to provide multi-touch support to unprivileged domains which may employ

[Xen-devel] [RFC] kbdif: add multi-touch support

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/kbdif.h | 64 +++ 1 file changed, 64 insertions(+) diff --git

Re: [Xen-devel] [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers

> + > +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid) > +{ > +struct avic_log_apic_id_ent *entry, new_entry; > +u32 *bp = avic_get_bk_page_entry(v, APIC_DFR); dfr would be a better name (and you use it in avic_handle_dfr_update()). Also, 'logical' instead of

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel wrote: > This patch relocates mem_access components that are currently mixed with p2m > code into separate files. This better aligns the code with similar subsystems, > such as mem_sharing and mem_paging, which are

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel wrote: > The only caller of this function is get_page_from_gva which already takes > a vcpu pointer as input. Pass this along to make the function in-line with > its intended use-case. > > Signed-off-by: Tamas K Lengyel

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

On 03/01/17 13:10, Jan Beulich wrote: > Most invocations of the instruction emulator are for VM exits where the > set of legitimate instructions (i.e. ones capable of causing the > respective exit) is rather small. Restrict the permitted sets via a new > callback, at once eliminating the abuse of

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

>>> On 03.01.17 at 15:56, wrote: > On 03/01/17 13:02, Jan Beulich wrote: >> This involves protmode_load_seg() accepting x86_seg_none as input, with >> the meaning to >> - suppress any exceptions other than #PF, >> - not commit any state. >> >> Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

On 03/01/17 13:02, Jan Beulich wrote: > This involves protmode_load_seg() accepting x86_seg_none as input, with > the meaning to > - suppress any exceptions other than #PF, > - not commit any state. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

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

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

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

>>> On 03.01.17 at 15:12, wrote: On 03.01.17 at 14:30, wrote: >> On 03/01/17 13:01, Jan Beulich wrote: >>> @@ -2716,36 +2716,36 @@ x86_emulate( >>> struct segment_register cs, sreg; >>> >>> case 0x00 ... 0x05: add: /* add */ >>>

Re: [Xen-devel] [PATCH v2 05/10] x86/HVM/SVM: Add AVIC initialization code

> + > +#define AVIC_DOORBELL 0xc001011b MSR_AVIC_DOORBELL (and it should probably go to include/asm-x86/msr-index.h) > + > +#define AVIC_HPA_SHIFT 12 Is there a reason not to use regular PAGE_SHIFT? > +#define AVIC_HPA_MASK (((1ULL << 40) - 1) << AVIC_HPA_SHIFT) >

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

>>> On 03.01.17 at 15:38, wrote: > Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict > -Werror checking"): >> Alistair Francis 12/22/16 8:14 PM >>> >> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all

[Xen-devel] [PATCH] uapi: use wildcards to list files

Regularly, when a new header is created in include/uapi/, the developer forgets to add it in the corresponding Kbuild file. This error is usually detected after the release is out. In fact, all headers under include/uapi/ should be exported, so let's use wildcards. After this patch, the

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking"): > Alistair Francis 12/22/16 8:14 PM >>> > >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues > >as I still see warnings/errors when building:

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

On 03/01/17 14:12, Jan Beulich wrote: > >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h >>> @@ -583,41 +583,9 @@ x86_emulate( >>> const struct x86_emulate_ops *ops); >>> >>> #ifndef NDEBUG >>> -/* >>> - * In debug builds, wrap x86_emulate()

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

>>> On 03.01.17 at 14:30, wrote: > On 03/01/17 13:01, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate.c >> @@ -21,6 +21,8 @@ >> #undef cpuid >> #undef wbinvd >> >> +#define r(name) r ## name >> + > > Hmm. I am no

[Xen-devel] [PATCH v6 07/12] pvh: Send an SCI on VCPU hotplug event

Send and SCI when VCPU map is updated by domctl or when guest sets GPE0 enable bit and status bit is already set. Also update send_guest_global_virq() to handle cases when VCPU0 is offlined. Signed-off-by: Boris Ostrovsky --- Changes in v6: * Change conditions

[Xen-devel] [PATCH v6 10/12] pvh: Set online VCPU map to avail_vcpus

ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT. With ACPI-based CPU hotplug we only want VCPUs that are started by the guest to be marked as such. Remaining VCPUs will be set to "enable" by AML code during hotplug. Signed-off-by: Boris Ostrovsky

[Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

Signed-off-by: Boris Ostrovsky Reviewed-by: Konrad Rzeszutek Wilk --- CC: George Dunlap CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan

[Xen-devel] [PATCH v6 11/12] pvh/acpi: Save ACPI registers for PVH guests

Signed-off-by: Boris Ostrovsky --- Can't generate SCI over event channel during is an event is enabled and pending: * v->virq_to_evtchn is not initialized yet (it's done by guest) * The SCI is sent immediately after event is made pending so it's not possible to miss

[Xen-devel] [PATCH v6 04/12] pvh/acpi: Handle ACPI accesses for PVH guests

Subsequent domctl access VCPU map will use the same code. We create acpi_cpumap_access_common() routines in anticipation of these changes. Signed-off-by: Boris Ostrovsky --- Changes in v6: * ACPI registers are only accessed by guest code (not by domctl), thus

[Xen-devel] [PATCH v6 03/12] pvh/acpi: Install handlers for ACPI-related PVH IO accesses

PVH guests will have ACPI accesses emulated by the hypervisor as opposed to QEMU (as is the case for HVM guests). This patch installs handler for accesses to PM1A, GPE0 (which is added to struct hvm_hw_acpi) and VCPU map. Logic for the handler will be provided by a later patch. Whether or not the

[Xen-devel] [PATCH v6 09/12] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

Provide libxc interface for accessing ACPI via XEN_DOMCTL_acpi_access. When a VCPU is hot-(un)plugged to/from a PVH guest update VCPU map by writing to ACPI's XEN_ACPI_CPU_MAP register and then set GPE0 status bit in GPE0.status. Signed-off-by: Boris Ostrovsky ---

[Xen-devel] [PATCH v6 05/12] x86/domctl: Handle ACPI access from domctl

Signed-off-by: Boris Ostrovsky --- Changes in v6: * Adjustments to to patch 4 changes. * Added a spinlock for VCPU map access * Return an error on guest trying to write VCPU map xen/arch/x86/hvm/acpi.c | 57 +++-

[Xen-devel] [PATCH v6 00/12] PVH VCPU hotplug support

This series adds support for ACPI-based VCPU hotplug for unprivileged PVH guests. Main changes in v6: * Generate SCI on VCPU map update by domctl * Simplify public domctl structure * Make ACPI registers accessible only by guest (and not by domctl) * Update VCPU map under lock * Fix pointer update

[Xen-devel] [PATCH v6 08/12] libxl: Update xenstore on VCPU hotplug for all guest types

Currently HVM guests that use upstream qemu do not update xenstore's availability entry for VCPUs. While it is not strictly necessary for hotplug to work, xenstore ends up not reflecting actual status of VCPUs. We should fix this. Signed-off-by: Boris Ostrovsky ---

[Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

Noone else needs to include it since it is only useful to code that can made domctl calls. And public domctl.h can only be included by the toolstack or the hypervisor. Signed-off-by: Boris Ostrovsky --- New in v6 (not required by the series). Q: Should

[Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

This domctl will allow toolstack to read and write some ACPI registers. It will be available to both x86 and ARM but will be implemented first only for x86 Signed-off-by: Boris Ostrovsky --- CC: Daniel De Graaf --- Changes in v6: * Fold

[Xen-devel] [PATCH v6 06/12] events/x86: Define SCI virtual interrupt

PVH guests do not have IOAPIC which typically generates an SCI. For those guests SCI will be provided as a virtual interrupt. Copy VIRQ_MCA definition from of xen-mca.h to xen.h to keep all x86-specific VIRQ_ARCH_* in one place. (However, because we don't want to require inclusion of xen.h in

[Xen-devel] [ovmf baseline-only test] 68309: all pass

This run is configured for baseline tests only. flight 68309 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68309/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7c6075e2546dd818b7b87090a983429b1942796a baseline

Re: [Xen-devel] [PATCH] xen: events: Replace BUG() with BUG_ON()

On 24/12/16 09:52, Shyam Saini wrote: > Replace BUG() with BUG_ON() using coccinelle > > Signed-off-by: Shyam Saini Committed to xen/tip.git for-linus-4.10 Thanks, Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

On 03/01/17 13:01, Jan Beulich wrote: > This is in preparation of eliminating the mis-naming of 64-bit fields > with 32-bit register names (eflags instead of rflags etc). > > Note that the result is not fully consistent until after at least one > more patch is in place, primarily to limit patch

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

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

[Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

Most invocations of the instruction emulator are for VM exits where the set of legitimate instructions (i.e. ones capable of causing the respective exit) is rather small. Restrict the permitted sets via a new callback, at once eliminating the abuse of handle_mmio() for non-MMIO operations.

Re: [Xen-devel] [PATCH] x86/VMX: use unambiguous register names

On 03/01/17 13:01, Jan Beulich wrote: > @@ -1321,10 +1321,10 @@ static void virtual_vmexit(struct cpu_us > if ( lm_l1 != lm_l2 ) > paging_update_paging_modes(v); > > -regs->eip = get_vvmcs(v, HOST_RIP); > -regs->esp = get_vvmcs(v, HOST_RSP); > +regs->rip = get_vvmcs(v,

[Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

This involves protmode_load_seg() accepting x86_seg_none as input, with the meaning to - suppress any exceptions other than #PF, - not commit any state. Signed-off-by: Jan Beulich --- v3: Re-base. v2: Extend commit message and add a respective code comment. Add ASSERT()s

[Xen-devel] [PATCH] x86/VMX: use unambiguous register names

This is in preparation of eliminating the mis-naming of 64-bit fields with 32-bit register names (eflags instead of rflags etc). Use the guaranteed 32-bit underscore prefixed names for now where appropriate. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vmcs.c +++

[Xen-devel] [PATCH] x86emul: use unambiguous register names

This is in preparation of eliminating the mis-naming of 64-bit fields with 32-bit register names (eflags instead of rflags etc). Note that the result is not fully consistent until after at least one more patch is in place, primarily to limit patch size (by trying to not touch the same line

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

>>> On 03.01.17 at 13:41, wrote: > On 03/01/17 12:40, Jan Beulich wrote: >> For the patch itself >> Reviewed-by: Jan Beulich > > Does this still stand if I split the patch into two, for easier backport? Yes. Jan

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

On 03/01/17 12:40, Jan Beulich wrote: On 03.01.17 at 13:06, wrote: >> Comparing 3 integers is more efficient than using strcmp(), and is more >> useful >> to the gcv_guest case than having to fabricate a suitable string to pass. >> The >> gcv_host cases have

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

>>> On 03.01.17 at 13:06, wrote: > Comparing 3 integers is more efficient than using strcmp(), and is more useful > to the gcv_guest case than having to fabricate a suitable string to pass. The > gcv_host cases have both options easily to hand, and experimentally, the

Re: [Xen-devel] [PATCH 1/2] x86/cpu: Drop unused X86_VENDOR_* values

>>> On 03.01.17 at 13:06, wrote: > Xen only has CPU drivers for Intel, Centaur and AMD. All other contributions > to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the > efficiency of get_cpu_vendor() > > There is one remaning hidden reference to

Re: [Xen-devel] [PATCH] x86/vvmx: Drop sreg_to_index[]

>>> On 03.01.17 at 12:58, wrote: > Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands", > x86_seg_* have followed hardware encodings, meaning that this translation > table is now an identiy transform. > > No functional change. > > Signed-off-by:

  1   2   >