[Xen-devel] [qemu-mainline test] 104153: regressions - FAIL

flight 104153 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 104106

Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories

On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote: > What I was trying to say is that I export those directories like other are. > Removing those files is not related to that series. Perhaps the correct solution is to only copy files matching "*.h" to reduce the risk of copying

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

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

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

On 01/12/2017 01:27 PM, Ian Jackson wrote: Dario Faggioli writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): Anyway, we should have some multi-socket boxes on OSSTest, AFAICR. I think we do but I haven't got a systematic way of answering that question other than by

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

flight 104156 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104156/ 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] PVH CPU hotplug design document

On 01/12/2017 02:00 PM, Andrew Cooper wrote: On 12/01/17 12:13, Roger Pau Monné wrote: ## Proposed solution using the STAO The general idea of this method is to use the STAO in order to hide the pCPUs from the hardware domain, and provide processor objects for vCPUs in an extra SSDT table.

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 01/12/2017 03:51 PM, Boris Ostrovsky wrote: > On 01/12/2017 03:48 PM, Andrew Cooper wrote: >> On 12/01/17 20:46, Boris Ostrovsky wrote: >>> On 01/12/2017 02:27 PM, Andrew Cooper wrote: On 12/01/17 18:00, Boris Ostrovsky wrote: >> Ahh! found it. This is a side effect of starting to

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

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

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

On Wed, 11 Jan 2017, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 11, 2017 at 10:49:15AM -0800, Stefano Stabellini wrote: > > On Wed, 4 Jan 2017, Stefano Stabellini wrote: > > > On Wed, 4 Jan 2017, Konrad Rzeszutek Wilk wrote: > > > > On Wed, Jan 04, 2017 at 10:00:01AM -0800, Stefano Stabellini

Re: [Xen-devel] [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

On Thu, 12 Jan 2017, Boris Ostrovsky wrote: > On 01/12/2017 04:33 PM, Stefano Stabellini wrote: > > On Thu, 12 Jan 2017, Boris Ostrovsky wrote: > >> On 01/11/2017 06:36 PM, Stefano Stabellini wrote: > >>> The following commit: > >>> > >>> commit 72a9b186292d98494f26cfd24a1621796209 > >>>

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

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

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 6:04 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 04:23:59PM -0600, Doug Goldstein wrote: >> On 1/12/17 2:28 PM, Daniel Kiper wrote: >>> On Thu, Jan 12, 2017 at 09:52:15AM -0600, Doug Goldstein wrote: On 1/12/17 6:50 AM, Daniel Kiper wrote: > On Wed, Jan 11, 2017 at

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 6:04 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 04:23:59PM -0600, Doug Goldstein wrote: >> On 1/12/17 2:28 PM, Daniel Kiper wrote: >>> On Thu, Jan 12, 2017 at 09:52:15AM -0600, Doug Goldstein wrote: On 1/12/17 6:50 AM, Daniel Kiper wrote: > On Wed, Jan 11, 2017 at

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On Thu, Jan 12, 2017 at 04:23:59PM -0600, Doug Goldstein wrote: > On 1/12/17 2:28 PM, Daniel Kiper wrote: > > On Thu, Jan 12, 2017 at 09:52:15AM -0600, Doug Goldstein wrote: > >> On 1/12/17 6:50 AM, Daniel Kiper wrote: > >>> On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote: > On

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On Thu, Jan 12, 2017 at 04:20:00PM -0600, Doug Goldstein wrote: > On 1/12/17 3:45 PM, Daniel Kiper wrote: > > On Thu, Jan 12, 2017 at 01:46:41PM -0600, Doug Goldstein wrote: > >> On 1/12/17 1:30 PM, Daniel Kiper wrote: > >>> On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: >

Re: [Xen-devel] [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

On 01/12/2017 12:17 PM, David Miller wrote: From: Vineeth Remanan Pillai Date: Wed, 11 Jan 2017 23:17:17 + @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int budget) napi_complete(napi);

[Xen-devel] [qemu-mainline test] 104148: regressions - FAIL

flight 104148 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104148/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104106 Regressions

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 2:28 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 09:52:15AM -0600, Doug Goldstein wrote: >> On 1/12/17 6:50 AM, Daniel Kiper wrote: >>> On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote: On 1/11/17 1:47 PM, Daniel Kiper wrote: > On Tue, Jan 10, 2017 at

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 3:45 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 01:46:41PM -0600, Doug Goldstein wrote: >> On 1/12/17 1:30 PM, Daniel Kiper wrote: >>> On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: >> >>> view there's no reason for adding MB2 support for BIOS since it

[Xen-devel] [PATCH v2] kexec: implement STATUS hypercall to check if image is loaded

The tools that use kexec are asynchronous in nature and do not keep state changes. As such provide an hypercall to find out whether an image has been loaded for either type. Note: No need to modify XSM as it has one size fits all check and does not check for subcommands. Note: No need to check

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On Thu, Jan 12, 2017 at 01:46:41PM -0600, Doug Goldstein wrote: > On 1/12/17 1:30 PM, Daniel Kiper wrote: > > On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: > > > > >> view there's no reason for adding MB2 support for BIOS since it provides > >> no advantage over MB1 when booting

Re: [Xen-devel] [PATCH v2] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c > index e8a9ea7..25a7c43 100644 > --- a/arch/x86/xen/spinlock.c > +++ b/arch/x86/xen/spinlock.c > @@ -141,25 +141,6 @@ void __init xen_init_spinlocks(void) > pv_lock_ops.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen); >

[Xen-devel] [PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

The following commit: commit 72a9b186292d98494f26cfd24a1621796209 Author: KarimAllah Ahmed Date: Fri Aug 26 23:55:36 2016 +0200 xen: Remove event channel notification through Xen PCI platform device broke Linux when booting as Dom0 on Xen in a nested Xen

Re: [Xen-devel] [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

On 01/12/2017 04:33 PM, Stefano Stabellini wrote: > On Thu, 12 Jan 2017, Boris Ostrovsky wrote: >> On 01/11/2017 06:36 PM, Stefano Stabellini wrote: >>> The following commit: >>> >>> commit 72a9b186292d98494f26cfd24a1621796209 >>> Author: KarimAllah Ahmed >>> Date: Fri

Re: [Xen-devel] [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

On Thu, 12 Jan 2017, Boris Ostrovsky wrote: > On 01/11/2017 06:36 PM, Stefano Stabellini wrote: > > The following commit: > > > > commit 72a9b186292d98494f26cfd24a1621796209 > > Author: KarimAllah Ahmed > > Date: Fri Aug 26 23:55:36 2016 +0200 > > > > xen: Remove

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

flight 104146 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104146/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 4 host-build-prep fail in 104136 REGR. vs. 104119 Tests which are

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 1:30 PM, Daniel Kiper wrote: > On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: > >> view there's no reason for adding MB2 support for BIOS since it provides >> no advantage over MB1 when booting from the BIOS. Now MB2 solves a > > From your point of view maybe it does

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 01/12/2017 03:48 PM, Andrew Cooper wrote: > On 12/01/17 20:46, Boris Ostrovsky wrote: >> On 01/12/2017 02:27 PM, Andrew Cooper wrote: >>> On 12/01/17 18:00, Boris Ostrovsky wrote: > Ahh! found it. This is a side effect of starting to generate the dom0 > policy in Xen. > > Can

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 12/01/17 20:46, Boris Ostrovsky wrote: > On 01/12/2017 02:27 PM, Andrew Cooper wrote: >> On 12/01/17 18:00, Boris Ostrovsky wrote: Ahh! found it. This is a side effect of starting to generate the dom0 policy in Xen. Can you try this patch? >>> Intel/AMD HVM/PV 64/32bit all

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 01/12/2017 02:27 PM, Andrew Cooper wrote: > On 12/01/17 18:00, Boris Ostrovsky wrote: >>> Ahh! found it. This is a side effect of starting to generate the dom0 >>> policy in Xen. >>> >>> Can you try this patch? >> Intel/AMD HVM/PV 64/32bit all look good. So >> >> Tested-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On Thu, Jan 12, 2017 at 09:52:15AM -0600, Doug Goldstein wrote: > On 1/12/17 6:50 AM, Daniel Kiper wrote: > > On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote: > >> On 1/11/17 1:47 PM, Daniel Kiper wrote: > >>> On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote: > On

[Xen-devel] [PATCH v2] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

This is a follow-up of commit cfd8983f03c7b2 ("x86, locking/spinlocks: Remove ticket (spin)lock implementation"). The static_key structure paravirt_ticketlocks_enabled is now removed as it is no longer used. As a result, the init functions kvm_spinlock_init_jump() and xen_init_spinlocks_jump() are

Re: [Xen-devel] [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai Date: Wed, 11 Jan 2017 23:17:17 + > @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int > budget) > napi_complete(napi); > > RING_FINAL_CHECK_FOR_RESPONSES(>rx, more_to_do); > -

Re: [Xen-devel] [PATCH] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c > index e8a9ea7..a822606 100644 > --- a/arch/x86/xen/spinlock.c > +++ b/arch/x86/xen/spinlock.c > @@ -155,7 +155,6 @@ static __init int xen_init_spinlocks_jump(void) > if (!xen_domain()) > return 0; > > -

[Xen-devel] [PATCH] x86/cpuid: Fix feature flags reported to dom0

c/s a11e8c9 "x86/pv: Use per-domain policy information in pv_cpuid()" switched PV domains from using a (hardware for dom0, toolstack-chosen from domU) value masked against pv_featureset[], to actually using the value calculated by recalculate_cpuid_policy(). For domU, this is no practical change

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On Thu, Jan 12, 2017 at 09:44:59AM -0600, Doug Goldstein wrote: > On 1/12/17 6:18 AM, Daniel Kiper wrote: > So as an aside, IMHO this is where the series should end and the next > set of patches should be a follow on. > >>> > >>> Hmmm... Why? If you do not apply rest of patches then MB2

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 12/01/17 18:00, Boris Ostrovsky wrote: >> Ahh! found it. This is a side effect of starting to generate the dom0 >> policy in Xen. >> >> Can you try this patch? > > Intel/AMD HVM/PV 64/32bit all look good. So > > Tested-by: Boris Ostrovsky Does this mean that newer

Re: [Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi, On 12/01/17 19:15, Stefano Stabellini wrote: > On Thu, 12 Jan 2017, Andre Przywara wrote: >> Hi Stefano, >> >> On 05/01/17 21:36, Stefano Stabellini wrote: >>> On Thu, 22 Dec 2016, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is

Re: [Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Thu, 12 Jan 2017, Andre Przywara wrote: > Hi Stefano, > > On 05/01/17 21:36, Stefano Stabellini wrote: > > On Thu, 22 Dec 2016, Andre Przywara wrote: > >> For the same reason that allocating a struct irq_desc for each > >> possible LPI is not an option, having a struct pending_irq for each LPI

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, as just mentioned in my last reply, I missed that email last time. Sorry for that. Replying to the comments that still apply to the new drop ... On 28/10/16 02:04, Stefano Stabellini wrote: > On Wed, 28 Sep 2016, Andre Przywara wrote: >> For the same reason that allocating a struct

[Xen-devel] libxl to json return string

Hi, I have an example attached below where I believe that libxl_physinfo_to_json() does not return all of the correct output. physinfo.c is the C program that outputs the json string. physc.out is the output that I recieved. physgo.out is the output I get using the golang bindings I'm creating

Re: [Xen-devel] PVH CPU hotplug design document

On 12/01/17 12:13, Roger Pau Monné wrote: > Hello, > > Below is a draft of a design document for PVHv2 CPU hotplug. It should cover > both vCPU and pCPU hotplug. It's mainly centered around the hardware domain, > since for unprivileged PVH guests the vCPU hotplug mechanism is already > described

Re: [Xen-devel] [RFC PATCH v2 10/26] ARM: GICv3: forward pending LPIs to guests

On Thu, 12 Jan 2017, Andre Przywara wrote: > On 05/01/17 22:10, Stefano Stabellini wrote: > > On Thu, 22 Dec 2016, Andre Przywara wrote: > >> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ > >> number to get this IRQ injected. > >> Iterate our two-level LPI table to find

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote: > > The other issue I heard about was some root file system corruptions after > > two or three re-boots we haven't observed in the native Linux case. The > > plan was to do some further analysis, first, before we blame Xen regarding > > this, though.

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

Dario Faggioli writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): > Anyway, we should have some multi-socket boxes on OSSTest, AFAICR. I think we do but I haven't got a systematic way of answering that question other than by manual eyeballing of the spec sheets. IF there

Re: [Xen-devel] Xen Community Call on new PV protocols, Tuesday 10th Jan 9AM PST

On Thu, 12 Jan 2017, Roger Pau Monné wrote: > On Tue, Jan 10, 2017 at 11:29:44AM -0800, Stefano Stabellini wrote: > > These are the minutes I took during the call: > > > > Xen PV Drivers Lifecycle document ready to be committed. > > > > Common Pitfalls for new PV protocols: > > - 32 vs 64 fields

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

On Thu, Jan 12, 2017 at 11:46:04AM -0600, Doug Goldstein wrote: > On 12/5/16 4:25 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending eleventh version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known issues. > > > >

Re: [Xen-devel] [PATCH] partially revert "xen: Remove event channel notification through Xen PCI platform device"

On 01/11/2017 06:36 PM, Stefano Stabellini wrote: > The following commit: > > commit 72a9b186292d98494f26cfd24a1621796209 > Author: KarimAllah Ahmed > Date: Fri Aug 26 23:55:36 2016 +0200 > > xen: Remove event channel notification through Xen PCI platform device > >

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

Dario Faggioli writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): > Maybe it's me misremembering/saying stupid things, but I recall that at > some point we were testing some of the recent and in development Linux > branches in OSSTest. We used to, but no-one fixed any of

Re: [Xen-devel] [RFC PATCH v2 09/26] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, On 05/01/17 21:36, Stefano Stabellini wrote: > On Thu, 22 Dec 2016, Andre Przywara wrote: >> For the same reason that allocating a struct irq_desc for each >> possible LPI is not an option, having a struct pending_irq for each LPI >> is also not feasible. However we actually only need

Re: [Xen-devel] [PATCH v2 5/5] libxl: Add explicit cast to libxl_psr_cat_set_cbm

On Tue, Jan 19, 2016 at 2:35 PM, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH v2 5/5] libxl: Add explicit cast to > libxl_psr_cat_set_cbm"): >> On Tue, 2016-01-19 at 14:06 +, Ian Jackson wrote: >> > * XEN_DOMCTL_PSR_CAT_OP_SET_L3_* (public/domctl.h) >> >

Re: [Xen-devel] [PATCH] xen-netback: fix memory leaks on XenBus disconnect

On 12/01/17 17:51, Igor Druzhinin wrote: > Eliminate memory leaks introduced several years ago by cleaning the queue > resources which are allocated on XenBus connection event. Namely, queue > structure array and pages used for IO rings. > vif->lock is used to protect statistics gathering agents

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

> Ahh! found it. This is a side effect of starting to generate the dom0 > policy in Xen. > > Can you try this patch? Intel/AMD HVM/PV 64/32bit all look good. So Tested-by: Boris Ostrovsky ___ Xen-devel mailing list

[Xen-devel] [PATCH] xen-netback: fix memory leaks on XenBus disconnect

Eliminate memory leaks introduced several years ago by cleaning the queue resources which are allocated on XenBus connection event. Namely, queue structure array and pages used for IO rings. vif->lock is used to protect statistics gathering agents from using the queue structure during cleaning.

[Xen-devel] [qemu-mainline test] 104142: regressions - FAIL

flight 104142 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104142/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 11 guest-start fail REGR. vs. 104106 Regressions

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

On 12/5/16 4:25 PM, Daniel Kiper wrote: > Hi, > > I am sending eleventh version of multiboot2 protocol support for > legacy BIOS and EFI platforms. This patch series release contains > fixes for all known issues. > > The final goal is xen.efi binary file which could be loaded by EFI > loader,

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

On Tue, Jan 10, 2017 at 01:35:39PM -0800, Laura Abbott wrote: > This is v7 of the patches to add CONFIG_DEBUG_VIRTUAL for arm64. This is > a simple reordering of patches from v6 per request of Will Deacon for ease > of merging support for arm which depends on this series. > > Laura Abbott (11): >

Re: [Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

On 12/01/17 16:37, Jan Beulich wrote: > While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode, > VEX.B can be encoded as zero, but would be ignored by the processor. Really? That is unfortunate. It would have been far more helpful for this to raise #UD, like the other prohibited

Re: [Xen-devel] Read Performance issue when Xen Hypervisor is activated

On Mon, 2017-01-02 at 07:15 +, Michael Schinzel wrote: > Good Morning, > I'm back, although, as anticipate, I can't be terribly useful, I'm afraid... > You can see, in default Xen configuration, the most important thing > at read performance test -> 2414.92 MB/sec <- the used cache is half >

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

On Thu, 2017-01-12 at 11:22 -0500, Boris Ostrovsky wrote: > On 01/12/2017 07:50 AM, Dario Faggioli wrote: > > I don't think we do that any longer, and that may be part of the > > reason > > why we missed this one? > > I believe you needed to be on a multi-socket system to catch this > bug. >

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns

On 12/01/17 16:12, Jan Beulich wrote: On 12.01.17 at 16:04, wrote: >> On 12/01/17 14:02, Jan Beulich wrote: >>> Furthermore I think we have another issue with writes: If the write >>> faults, the FSW (or MXCSR, albeit there only for instructions we don't >>>

Re: [Xen-devel] [PATCH v3 8/8] x86/hvm: serialize trap injecting producer and consumer

>>> On 12.01.17 at 17:28, wrote: > On 12/01/17 14:58, Paul Durrant wrote: >> Since injection works on a remote vCPU, and since there's no >> enforcement of the subject vCPU being paused, there's a potential race >> between the producing and consuming sides. Fix this by

[Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode, VEX.B can be encoded as zero, but would be ignored by the processor. Since we emulate instructions in 64-bit mode, we need to force the bit to 1 in order to not act on the wrong {X,Y,Z}MM register. We must not, however, fiddle

Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories

On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: >Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: >>> Regularly, when a new header is created in include/uapi/, the developer >>> forgets to add it in the corresponding

Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories

Le 12/01/2017 à 17:28, Jan Engelhardt a écrit : > On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: > >> Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: Regularly, when a new header is created in include/uapi/, the

Re: [Xen-devel] [PATCH v3 8/8] x86/hvm: serialize trap injecting producer and consumer

On 12/01/17 14:58, Paul Durrant wrote: > Since injection works on a remote vCPU, and since there's no > enforcement of the subject vCPU being paused, there's a potential race > between the producing and consuming sides. Fix this by leveraging the > vector field as synchronization variable. > >

Re: [Xen-devel] [PATCH v3 2/8] dm_op: convert HVMOP_*ioreq_server*

>>> On 12.01.17 at 15:58, wrote: > The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are > already in use by callers of the libxc interface. > > Suggested-by: Jan Beulich > Signed-off-by: Paul Durrant > -- >

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

On 01/12/2017 07:50 AM, Dario Faggioli wrote: > On Wed, 2017-01-04 at 22:13 -0500, Boris Ostrovsky wrote: >> On 01/04/2017 09:10 PM, Konrad Rzeszutek Wilk wrote: >>> On Wed, Jan 04, 2017 at 08:52:03PM -0500, Konrad Rzeszutek Wilk >>> wrote: I was trying to bootup on an 30 CPU machine (15

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 12/01/17 15:50, Boris Ostrovsky wrote: > On 01/12/2017 10:31 AM, Andrew Cooper wrote: >> On 12/01/17 15:22, Boris Ostrovsky wrote: case 0x8001: -c &= pv_featureset[FEATURESET_e1c]; -d &= pv_featureset[FEATURESET_e1d]; +c = p->extd.e1c; >>>

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns

>>> On 12.01.17 at 16:04, wrote: > On 12/01/17 14:02, Jan Beulich wrote: >> Furthermore I think we have another issue with writes: If the write >> faults, the FSW (or MXCSR, albeit there only for instructions we don't >> emulate yet) register may have been updated

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

According the code around the assert: movzbl %r14b, %esi 41 0f b6 f6 cmp %esi, %eax 39 f0 jle ... 7e 02 ud2 <0f> 0b mov %rbx, %rdi 48 89 df callq ... e8 51 20 00 00 mov $0x810, %eaxb8 10 08 00 00 so I think one is 0x38 %eax, the other is

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

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

Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories

Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : > On Fri, Jan 06, 2017 at 10:43:59AM +0100, 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

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 6:50 AM, Daniel Kiper wrote: > On Wed, Jan 11, 2017 at 02:20:15PM -0600, Doug Goldstein wrote: >> On 1/11/17 1:47 PM, Daniel Kiper wrote: >>> On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote: On 1/9/17 7:37 PM, Doug Goldstein wrote: > On 12/5/16 4:25 PM, Daniel

[Xen-devel] [PATCH] x86, locking/spinlocks: Remove paravirt_ticketlocks_enabled

This is a follow-up of commit cfd8983f03c7b2 ("x86, locking/spinlocks: Remove ticket (spin)lock implementation"). The static_key structure paravirt_ticketlocks_enabled is now removed as it is no longer used. A simple build and boot test was done to verify it. Signed-off-by: Waiman Long

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 01/12/2017 10:31 AM, Andrew Cooper wrote: > On 12/01/17 15:22, Boris Ostrovsky wrote: >>> case 0x8001: >>> -c &= pv_featureset[FEATURESET_e1c]; >>> -d &= pv_featureset[FEATURESET_e1d]; >>> +c = p->extd.e1c; >> This appears to crash guests Intel, at least for

Re: [Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

On 1/12/17 6:18 AM, Daniel Kiper wrote: So as an aside, IMHO this is where the series should end and the next set of patches should be a follow on. >>> >>> Hmmm... Why? If you do not apply rest of patches then MB2 does not >>> work on all EFI platforms. >>> >>> Daniel >> >> So I

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi, On 01/03/2017 12:33 PM, Dirk Behme wrote: > On 20.12.2016 19:01, Julien Grall wrote: >> Hi Andrii, >> >> On 20/12/2016 19:00, Andrii Anisov wrote: >>> Sorry for the mess, >>> >>> I mean the xen-swiotlb issue on renesas board: >>> Bosch: problem with xen-swiotlb. It does not work properly

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 12/01/17 14:58, Paul Durrant wrote: > ...as a set of hypercalls to be used by a device model. > > As stated in the new docs/designs/dm_op.markdown: > > "The aim of DMOP is to prevent a compromised device model from > compromising domains other then the one it is associated with. (And is >

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

On 12/01/17 15:22, Boris Ostrovsky wrote: >> case 0x8001: >> -c &= pv_featureset[FEATURESET_e1c]; >> -d &= pv_featureset[FEATURESET_e1d]; >> +c = p->extd.e1c; > This appears to crash guests Intel, at least for dom0. Is this a PVH dom0? I can't see from this

Re: [Xen-devel] [PATCH v2 16/25] x86/pv: Use per-domain policy information in pv_cpuid()

> case 0x8001: > -c &= pv_featureset[FEATURESET_e1c]; > -d &= pv_featureset[FEATURESET_e1d]; > +c = p->extd.e1c; This appears to crash guests Intel, at least for dom0. p->extd.e1c is 0x3 and bit 1 is reserved on Intel. I haven't traced it yet to exact place

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns

On 12/01/17 14:02, Jan Beulich wrote: > FPU insns writing to memory must not touch memory if they latch #MF (to > be delivered on the next waiting FPU insn). Note that inspecting FSW.ES > needs to be avoided for all FNST* insns, as they don't raise exceptions > themselves, but may instead be

[Xen-devel] [PATCH v3 6/8] dm_op: convert HVMOP_set_mem_type

This patch removes the need for handling HVMOP restarts, so that infrastructure is removed. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan

[Xen-devel] [PATCH v3 3/8] dm_op: convert HVMOP_track_dirty_vram

The handle type passed to the underlying shadow and hap functions is changed for compatibility with the new hypercall buffer. NOTE: This patch also modifies the type of the 'nr' parameter of xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice the value passed was always

[Xen-devel] [PATCH v3 8/8] x86/hvm: serialize trap injecting producer and consumer

Since injection works on a remote vCPU, and since there's no enforcement of the subject vCPU being paused, there's a potential race between the producing and consuming sides. Fix this by leveraging the vector field as synchronization variable. Signed-off-by: Jan Beulich

[Xen-devel] [PATCH v3 5/8] dm_op: convert HVMOP_modified_memory

This patch introduces code to handle DMOP continuations. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits. Suggested-by: Jan Beulich

[Xen-devel] [PATCH v3 0/8] New hypercall for device models

Following on from the design submitted by Jennifer Herbert to the list [1] this series provides an implementation of __HYPERCALL_dm_op followed by patches based on Jan Beulich's previous HVMCTL series [2] to convert tools-only HVMOPs used by device models to DMOPs. [1]

[Xen-devel] [PATCH v3 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

... HVMOP_set_pci_link_route These HVMOPs were exposed to guests so their definitions need to be preserved for compatibility. This patch therefore updates __XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.

[Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

...as a set of hypercalls to be used by a device model. As stated in the new docs/designs/dm_op.markdown: "The aim of DMOP is to prevent a compromised device model from compromising domains other then the one it is associated with. (And is therefore likely already compromised)." See that file

[Xen-devel] [PATCH v3 2/8] dm_op: convert HVMOP_*ioreq_server*

The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are already in use by callers of the libxc interface. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant -- Reviewed-by: Jan Beulich Cc: Ian Jackson

Re: [Xen-devel] [PATCH v5 2/4] x86emul: support VME and PVI

On 12/01/17 14:15, Jan Beulich wrote: > ... affecting PUSHF, POPF, CLI, and STI. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v5 1/4] x86emul: conditionally clear BNDn for branches

On 12/01/17 14:15, Jan Beulich wrote: > Considering that we surface MPX to HVM guests, instructions we emulate > should also correctly deal with MPX state. While for now BND* > instructions don't get emulated, the effect of branches (which we do > emulate) without BND prefix should be taken care

[Xen-devel] [PATCH v5 3/4] x86emul: use switch()-wide local variable 'cr4'

... rather than various smaller scope ones. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- v2: Re-base over PUSHF adjustment in earlier patch. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@

[Xen-devel] [PATCH v5 4/4] x86emul: improve CR/DR access handling

- don't accept LOCK for DR accesses (it's undefined in the manuals) - only accept LOCK for CR accesses when the respective feature flag is set (which would not normally be the case for Intel) - add (rather than or) 8 when LOCK is present; real hardware #UDs when both REX.W and LOCK are

Re: [Xen-devel] [PATCH] x86/cpuid: Move vendor/family/model information from arch_domain to cpuid_policy

On 12/01/17 14:13, Jan Beulich wrote: On 12.01.17 at 15:02, wrote: >> I did make get_cpu_vendor() quite a lot better than it was previously, >> but it is still searching a loop. For the extra 3 bytes of data, I >> still think pre-calculating the values is worth

[Xen-devel] [PATCH v5 2/4] x86emul: support VME and PVI

... affecting PUSHF, POPF, CLI, and STI. Signed-off-by: Jan Beulich --- v5: Add PUSHF adjustment. mode_pvi() -> mode_vif(). --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -433,6 +433,8 @@ typedef union { #define CR0_EM(1<<2)

[Xen-devel] [PATCH v5 1/4] x86emul: conditionally clear BNDn for branches

Considering that we surface MPX to HVM guests, instructions we emulate should also correctly deal with MPX state. While for now BND* instructions don't get emulated, the effect of branches (which we do emulate) without BND prefix should be taken care of. No need to alter XABORT behavior: While

Re: [Xen-devel] [PATCH] x86/cpuid: Move vendor/family/model information from arch_domain to cpuid_policy

>>> On 12.01.17 at 15:02, wrote: > I did make get_cpu_vendor() quite a lot better than it was previously, > but it is still searching a loop. For the extra 3 bytes of data, I > still think pre-calculating the values is worth it. Well, as said, the question isn't the

[Xen-devel] [PATCH v5 0/4] x86emul: further misc improvements

1: conditionally clear BNDn for branches 2: support VME and PVI 3: use switch()-wide local variable 'cr4' 4: improve CR/DR access handling Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] x86/cpuid: Move vendor/family/model information from arch_domain to cpuid_policy

On 12/01/17 13:40, Jan Beulich wrote: On 12.01.17 at 13:32, wrote: >> --- a/xen/arch/x86/domctl.c >> +++ b/xen/arch/x86/domctl.c >> @@ -78,12 +78,11 @@ static void update_domain_cpuid_info(struct domain *d, >> switch ( ctl->input[0] ) >> { >> case 0:

  1   2   >