Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, January 23, 2017 10:41 PM > > On 16/01/17 11:17, Andrew Cooper wrote: > > If the hardware supports faulting, and the guest has chosen to use it, leave > > faulting active in HVM context. > > > > It is more efficient to have h

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

>>> On 23.01.17 at 18:12, wrote: > On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote: >> >>> On 23.01.17 at 17:42, wrote: >> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: >> >> >>> On 17.01.17 at 18:14, wrote: >> >> > This can be solved by using a different ACPI name i

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

>>> On 23.01.17 at 19:36, wrote: I think this should be introduced in your DomU ACPI CPU hotplug series, and not set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 also. >>> Right, although my understanding is that the series is on hold until we >>>

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

On 01/23/2017 09:49 PM, Stefano Stabellini wrote: On Sat, 21 Jan 2017, Oleksandr Andrushchenko wrote: In the mail-thread you mentioned above there is a picture of the xenstore entries and conclusion: 1. No change to the existing kbd+ptr: 1.1. They still share a dedicated (single) connection cha

[Xen-devel] Xen installation on Nvidia Jetson TK-1

Hello, I am trying to install xen on Nvidia Jetson TK1. I am using this repo *git://xenbits.xen.org/people/ianc/xen.git branch : tegra-tk1-jetson-v1* I tried *make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32 to build using this

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

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

[Xen-devel] Bad block Management Patch

Hi Boris, I am using kernel version-3.0.35 I am facing uncorrectable ECC error in ubifs. I am suspecting, it is because of bad blocks are not properly handled in my driver. Is there any patches available to handle the bad block in the specified version... Best regards Raghavan Anurag RBEI/ET

[Xen-devel] [qemu-mainline test] 104611: tolerable FAIL - PUSHED

flight 104611 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/104611/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 104609 pass in 104611 test-armhf-armhf-libvirt-x

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

On Mon, 23 Jan 2017, Julien Grall wrote: > Hi all, > > Before someone dig into the scheduler, I don't think this is an issue in > credit2 but the use of it highlight a bug in another component (I think RCU). > > Whilst testing other patches today, I have noticed that some part of the > resources

Re: [Xen-devel] [DOC v7] PV Calls protocol design

On Fri, 20 Jan 2017, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 10, 2017 at 04:13:26PM -0800, Stefano Stabellini wrote: > > Upon request from Konrad, I am attaching the output of pahole on the C > > structs defined by PVCalls. As you can see, alignments and sizes of all > > Thank you! > > fields a

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

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

[Xen-devel] [ovmf baseline-only test] 68423: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68423 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68423/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken bas

[Xen-devel] [distros-debian-sid test] 68422: tolerable trouble: blocked/broken

flight 68422 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68422/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3) broken like 68374 build-armhf-pvops

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

On Sat, 21 Jan 2017, Oleksandr Andrushchenko wrote: > In the mail-thread you mentioned above there is a picture of > the xenstore entries and conclusion: > > 1. No change to the existing kbd+ptr: > 1.1. They still share a dedicated (single) connection > channel as they did before multi-touch: page

[Xen-devel] xen/arm: Domain not fully destroyed when using credit2

Hi all, Before someone dig into the scheduler, I don't think this is an issue in credit2 but the use of it highlight a bug in another component (I think RCU). Whilst testing other patches today, I have noticed that some part of the resources allocated to a guest were not released during the

Re: [Xen-devel] [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

On 01/23/2017 05:09 AM, Juergen Gross wrote: > Handling of multiple concurrent Xenstore accesses through xenbus driver > either from the kernel or user land is rather lame today: xenbus is > capable to have one access active only at one point of time. > > Rewrite xenbus to handle multiple requests

Re: [Xen-devel] [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()

On 01/23/2017 09:39 AM, Andrew Cooper wrote: > Leaf 0x801c contains LWP information. edx contains hardware supported > features (and is clamped against the maximum), while ecx and ebx contain > various properties of the implementation. eax is entirely dynamic, depending > on xcr0 and MSR_LWP_

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

>>> I think this should be introduced in your DomU ACPI CPU hotplug series, and >>> not >>> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 >>> also. >>> >> Right, although my understanding is that the series is on hold until we >> come to agreement about what to do about

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Mon, Jan 23, 2017 at 10:07:36AM -0600, Doug Goldstein wrote: > On 1/23/17 9:45 AM, Daniel Kiper wrote: > > On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: > >> On 1/23/17 7:08 AM, Daniel Kiper wrote: > >>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > On Fr

[Xen-devel] [PATCH v14 3/3] iommu: add rmrr Xen command line option for extra rmrrs

On some platforms firmware fails to specify RMRR regions in ACPI tables and thus those regions will not be mapped in dom0 or guests and may cause IO Page Faults and prevent dom0 from booting if "iommu=dom0-strict" option is specified on the Xen command line. New Xen command line option rmrr allows

[Xen-devel] [PATCH v14 2/3] pci: add wrapper for parse_pci.

For sbdf's parsing in RMRR command line, add parse_pci_seg with additional parameter def_seg. parse_pci_seg will help to identify if segment was found in string being parsed or default segment was used. Make a wrapper parse_pci so the rest of the callers are not affected. Signed-off-by: Elena Ufim

[Xen-devel] [PATCH v14 1/3] iommu VT-d: separate rmrr addition function.

In preparation for auxiliary RMRR data provided on Xen command line, make RMRR adding a separate function. Also free memery for rmrr device scope in error path. Signed-off-by: Elena Ufimtseva Signed-off-by: Venu Busireddy Acked-by: Kevin Tian --- xen/drivers/passthrough/vtd/dmar.c | 123 ++

[Xen-devel] [PATCH v14 0/3] iommu: add rmrr Xen command line option

Add Xen command line option rmrr to specify RMRR regions that are not defined in ACPI thus causing IO Page Faults and prevent dom0 from booting if "iommu=dom0-strict" option is specified on the Xen command line. These additional regions will be added to the list of RMRR regions parsed from ACPI. C

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Mon, Jan 23, 2017 at 10:03:52AM -0600, Doug Goldstein wrote: > On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote: > > On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote: > >> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Dou

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

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

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

On Mon, Jan 23, 2017 at 12:05:11PM -0500, Boris Ostrovsky wrote: > On 01/23/2017 11:50 AM, Roger Pau Monné wrote: > > On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote: > >> On 01/23/2017 10:58 AM, Jan Beulich wrote: > >> On 23.01.17 at 16:49, wrote: > On 01/23/2017 10:43 AM

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

On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote: > >>> On 23.01.17 at 17:42, wrote: > > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: > >> >>> On 17.01.17 at 18:14, wrote: > >> > This can be solved by using a different ACPI name in order to describe > >> > vCPUs in > >

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

On 01/23/2017 11:50 AM, Roger Pau Monné wrote: > On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote: >> On 01/23/2017 10:58 AM, Jan Beulich wrote: >> On 23.01.17 at 16:49, wrote: On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: >>> From Linux perspective one option could be

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

>>> On 23.01.17 at 17:42, wrote: > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: >> >>> On 17.01.17 at 18:14, wrote: >> > This can be solved by using a different ACPI name in order to describe >> > vCPUs in >> > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefi

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

On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote: > On 01/23/2017 10:58 AM, Jan Beulich wrote: > On 23.01.17 at 16:49, wrote: > >> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: > > From Linux perspective one option could be to have domU with PV-style > > vCPU on/offlin

Re: [Xen-devel] [sun8i][H3] Question about running Xen on OrangePi PC

Thanks Julien, Finally, I am able to run latest Xen 4.9,latest Linux kernel 4.9 and latest buildroot on orangepi PC and NenoPi-M1 board. Now,I want to run RTOS VM on Xen and pin the CPU to RTOS VM so i can achieve real time response from RTOS VM. Long term I want to do GPU(on Mali) virtualizatio

[Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

Create a basic Makefile to build and install libxenlight Golang bindings. Also add a stub package which only opens libxl context. Include a global xenlight.Ctx variable which can be used as the default context by the entire program if desired. For now, return simple errors. Proper error handling

[Xen-devel] [PATCH RFC 6/8] golang/xenlight: Implement libxl_bitmap and helper operations

Implement Bitmap type, along with helper functions. The Bitmap type is implemented interllay in a way which makes it easy to copy into and out of the C libxl_bitmap type. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 166 ++

[Xen-devel] [PATCH RFC 4/8] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

Add calls for the following host-related functionality: - libxl_domain_info - libxl_domain_unpause Include Golang version for the libxl_domain_info as DomainInfo. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 92 +++

[Xen-devel] [PATCH RFC 8/8] golang/xenlight: Implement cpupool operations

Include some useful "Utility" functions: - CpupoolFindByName - CpupoolMakeFree Still need to implement the following functions: - libxl_cpupool_rename - libxl_cpupool_cpuadd_node - libxl_cpupool_cpuremove_node - libxl_cpupool_movedomain Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas -

[Xen-devel] [PATCH RFC 7/8] golang/xenlight: Implement libxl_scheduler enumeration

Include both constants and a Stringification for libxl_scheduler. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 62 +++ 1 file changed, 62 insertions(+) diff --git a/tools/golang/xenlight/xenlight.go b/tool

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

On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: > >>> On 17.01.17 at 18:14, wrote: > > This can be solved by using a different ACPI name in order to describe > > vCPUs in > > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for > > the processor objects, so us

[Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

Create error type Errorxl for throwing proper xenlight errors. Update Ctx functions to throw Errorxl errors. Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 75 ++- 1 file changed, 74 insertions(+), 1 deletion(-) diff --git a/tools/golang

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

>>> On 17.01.17 at 18:14, wrote: > This can be solved by using a different ACPI name in order to describe vCPUs > in > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should > prevent clashes. I

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

On 01/23/2017 10:58 AM, Jan Beulich wrote: On 23.01.17 at 16:49, wrote: >> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: > From Linux perspective one option could be to have domU with PV-style > vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when > it becomes a

Re: [Xen-devel] [PATCH v7 06/14] firmware/Makefile: force recompilation if makefile changes

On Thu, Jan 19, 2017 at 12:19:15PM +0100, Greg KH wrote: > On Sun, Jan 15, 2017 at 01:10:49PM -0800, Luis R. Rodriguez wrote: > > If you modify the target asm we currently do not force the > > recompilation of the firmware files. The target asm is in > > the firmware/Makefile, peg this file as a de

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/23/17 9:45 AM, Daniel Kiper wrote: > On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: >> On 1/23/17 7:08 AM, Daniel Kiper wrote: >>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > On 1/19/1

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote: >> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: >>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: On 1/19/17 8:34 PM, Daniel Kiper wrote: > Hi

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

>>> On 23.01.17 at 16:49, wrote: > On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: From Linux perspective one option could be to have domU with PV-style vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when it becomes available. This, however, will need an indication

Re: [Xen-devel] [PATCH 4/5] xen: sched: impove use of cpumask scratch space in Credit1.

On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli wrote: > It is ok to use just cpumask_scratch in csched_runq_steal(). > In fact, the cpu parameter comes from the cpu local variable > in csched_load_balance(), which in turn comes from cpu in > csched_schedule(), which is smp_processor_id(). > > Whi

Re: [Xen-devel] [PATCH 5/5] xen: sched: simplify ACPI S3 resume path.

On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli wrote: > In fact, when domains are being unpaused: > - it's not necessary to put the vcpu to sleep, as >they are all already paused; > - it is not necessary to call vcpu_migrate(), as >the vcpus are still paused, and therefore won't >wa

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

>>> On 23.01.17 at 16:43, wrote: >>> From Linux perspective one option could be to have domU with PV-style >>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >>> it becomes available. This, however, will need an indication from the >>> hypervisor. We could, for example, set

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

On 01/23/2017 10:43 AM, Boris Ostrovsky wrote: >>> From Linux perspective one option could be to have domU with PV-style >>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >>> it becomes available. This, however, will need an indication from the >>> hypervisor. We could, for

Re: [Xen-devel] [PATCH 3/5] xen: credit2: fix shutdown/suspend when playing with cpupools.

On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli wrote: > In fact, during shutdown/suspend, we temporarily move all > the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2 > domains, we call csched2_vcpu_migrate(), expects to find the > target pCPU in the domain's pool > > Therefore, if Credi

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: > On 1/23/17 7:08 AM, Daniel Kiper wrote: > > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > >>> On 1/19/17 8:34 PM, Daniel Kiper wrote: > Hi, >

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

>> From Linux perspective one option could be to have domU with PV-style >> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when >> it becomes available. This, however, will need an indication from the >> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we >> discu

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On 1/23/17 7:08 AM, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: >>> On 1/19/17 8:34 PM, Daniel Kiper wrote: Hi, I am sending twelfth version of multiboot2 protocol support for >

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli wrote: > In fact, relying on the mask of what pCPUs belong to > which Credit2 runqueue is not enough. If we only do that, > when Credit2 is the boot scheduler, we may ASSERT() or > panic when moving a pCPU from Pool-0 to another cpupool. > > This is

[Xen-devel] [PATCH] xen-blkfront: correct maximum segment accounting

Making use of "max_indirect_segments=" has issues: - blkfront_setup_indirect() may end up with zero psegs when PAGE_SIZE is sufficiently much larger than XEN_PAGE_SIZE - the variable driven by the command line option (xen_blkif_max_segments) has a somewhat different purpose, and hence should

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

>>> On 23.01.17 at 15:28, wrote: > On 01/23/2017 05:35 AM, Jan Beulich wrote: > On 22.01.17 at 19:39, wrote: >>> On 01/18/2017 08:25 AM, Jan Beulich wrote: >>> On 18.01.17 at 12:54, wrote: > So, would it be fine to start a PVH Dom0 with as many vCPUs as what's > returned > f

[Xen-devel] [PATCH] xen-blkfront: feature flags handling adjustments

Don't truncate the "feature-persistent" value read from xenstore: Any non-zero value is supposed to enable the feature, just like is already being done for feature_secdiscard. Just like the other feature_* fields, feature_flush and feature_fua are boolean flags, and hence fit well into a single bi

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

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

[Xen-devel] [ovmf baseline-only test] 68421: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68421 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68421/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken bas

Re: [Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()

On Mon, Jan 23, 2017 at 02:39:14PM +, Andrew Cooper wrote: > Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf > 0x801a is performance hints. These leaves have previously been hidden > from guests, but are perfectly safe to expose. > > Update libxc to also exp

[Xen-devel] [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves

All leaves in the extd union are handled in guest_cpuid() now, so remove legacy handling. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c| 14 +++--- xen/include/asm-x86/cpuid.h | 4 ++-- 2 files changed, 5 insertions(+), 13 deletions(-) diff --git a/

[Xen-devel] [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()

Leaf 0x801c contains LWP information. edx contains hardware supported features (and is clamped against the maximum), while ecx and ebx contain various properties of the implementation. eax is entirely dynamic, depending on xcr0 and MSR_LWP_CFG. The call to guest_cpuid() in svm_update_lwp_cfg

[Xen-devel] [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests

Xen advertises the IBS feature flag to guests on capable AMD hardware. However, the PV path in Xen, and both the PV and HVM paths in libxc deliberately clobber the IBS CPUID leaf. Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so guests can't actually use the feature at

[Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()

Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf 0x801a is performance hints. These leaves have previously been hidden from guests, but are perfectly safe to expose. Update libxc to also expose these leaves. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC:

[Xen-devel] [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a in guest_cpuid()

Leaf 0x800a contains SVM information. The feature choices are borrowed straight from the libxc policy code. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * New --- xen/arch/x86/cpuid.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

On Mon, Jan 23, 2017 at 09:11:06AM -0500, Boris Ostrovsky wrote: > > > > > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn, > > + unsigned long nr_pages, bool map) > > +{ > > +int rc; > > + > > +for ( ; ; ) > > +{ > >

[Xen-devel] [linux-next test] 104604: tolerable FAIL

flight 104604 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/104604/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt

Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

On 16/01/17 11:17, Andrew Cooper wrote: > If the hardware supports faulting, and the guest has chosen to use it, leave > faulting active in HVM context. > > It is more efficient to have hardware convert CPUID to a #GP fault (which we > don't intercept), than to take a VMExit and have Xen re-inject

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

On Thu, Jan 19, 2017 at 8:08 AM, Juergen Gross wrote: > On 17/01/17 18:26, Dario Faggioli wrote: >> In fact, relying on the mask of what pCPUs belong to >> which Credit2 runqueue is not enough. If we only do that, >> when Credit2 is the boot scheduler, we may ASSERT() or >> panic when moving a pCP

[Xen-devel] [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()

Intel now document leaf 2 as a plain leaf, with %al always containing the value 0x01. Collect this leaf normally in calculate_raw_policy() and expose it to guests. The leaf is reserved by AMD. Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at all. They are reserved by

[Xen-devel] [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()

The calculations for p->extd.max_leaf are reworked to force a value of at least 0x8000, and to take the domains chosen vendor into account when clamping maximum value. The high short vendor information is clobbered or duplicated according to the chosen vendor. As a side effect of handing out

[Xen-devel] [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests

Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses to optimise its cache flushing algorithm. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné v2: * New --- xen/include/public/arch-x86/cpufeatureset.h | 1 + 1 file changed, 1 insertion(+) diff

[Xen-devel] [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid()

The series has been extended substantially, and now handles the entire extd union in the guest_cpuid() path. Andrew Cooper (14): x86/cpufeatures: Expose self-snoop to all guests x86/cpuid: Handle leaf 0x8000 in guest_cpuid() x86/cpuid: Only recalculate the shared feature bits once x86/

[Xen-devel] [PATCH v2 06/14] x86/cpuid: Handle the long vendor string in guest_cpuid()

Leaves 0x8002 through 0x8004 are plain ASCII text, and are left exactly as the toolstack chooses. Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein Reviewed-by: Jan Beulich --- v2: * Rebased, but no significant changes --- xen/arch/x86/cpuid.c | 6 +++--- 1 file changed, 3 inse

[Xen-devel] [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()

Leaf 0x8005 contains L1 cache/TLB information, 0x8006 L2 & L3 cache/TLB information, and 0x8007 Power management information. Intel reserves all of this information other than the L2 cache information, and the ITSC bit from the power management leaf. AMD passes all of the cache/TLB in

[Xen-devel] [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()

The entirety of edx is reserved. Intel only defines the lower 16 bits of eax, although ebx is covered by the featureset ABI, so left unclobbered. AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero guest maxphysaddr to HVM guests. ecx contains some reserved bits, and s

[Xen-devel] [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()

Intel reserve eax and ebx, while AMD duplicates eax from the low family/model/stepping leaf. For AMD, ebx contains further brand/package information which is left as the toolstack chooses (other than bits 27:16 which are reserved). While moving the dynamic adjustments from the legacy path, simpli

[Xen-devel] [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once

With accurate vendor information available, the shared bits can be sorted out during recalculation, rather than at query time in the legacy cpuid path. This means that: * Duplication can be dropped from the automatically generated cpuid data. * The toolstack need not worry about setting them app

[Xen-devel] [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 in guest_cpuid()

Leaf 0x8009 is reserved. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * New --- xen/arch/x86/cpuid.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index 4d48552..a8dce40 100644 --- a/xen/arch/x86/cpuid.c +++

Re: [Xen-devel] [linux-linus test] 104237: regressions - FAIL

On 01/23/2017 07:16 AM, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions - > FAIL"): >> I'm inclined to increasing the timeout, although this slowness does >> mean that our tests may be blocked more than we would like. > I have set the host property

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > > > Hi, > > > > > > > > I am sending twelfth version of

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

On 01/23/2017 05:35 AM, Jan Beulich wrote: On 22.01.17 at 19:39, wrote: >> On 01/18/2017 08:25 AM, Jan Beulich wrote: >> On 18.01.17 at 12:54, wrote: So, would it be fine to start a PVH Dom0 with as many vCPUs as what's returned from dom0_max_vcpus, and mark them as enabl

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

> > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn, > + unsigned long nr_pages, bool map) > +{ > +int rc; > + > +for ( ; ; ) > +{ > +rc = (map ? map_mmio_regions : unmap_mmio_regions) This can be taken outsid

[Xen-devel] [xtf test] 104606: all pass - PUSHED

flight 104606 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104606/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 7e1bc8009286dcf505a1be3587d8d8388d8ab95d baseline version: xtf ee3e2656886a3bfdee19c7

[Xen-devel] [PATCH v7 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 Acked-by: Wei Liu Acked-by: Daniel De Graaf Reviewed-by: Andrew Cooper -- Cc: Ian Jackson

[Xen-devel] [PATCH v7 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 tr

[Xen-devel] [PATCH v7 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 v7 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 fo

[Xen-devel] [PATCH v7 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 Signed-off-by: Paul Dur

[Xen-devel] [PATCH v7 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

NOTE: This patch also modifies the types of the 'vector', 'type' and 'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to uint8_t. In practice the values passed were always truncated to 8 bits. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant Reviewed-by: Jan Beul

[Xen-devel] [PATCH v7 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] https://lists.xenproject.org

[Xen-devel] [PATCH v7 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 [re-based] Signed-off-by:

[Xen-devel] [PATCH v7 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. N

[Xen-devel] [PATCH XTF] also test AVX exceptions

... as they're different from SSE and FPU ones. Signed-off-by: Jan Beulich --- a/include/arch/x86/cpuid.h +++ b/include/arch/x86/cpuid.h @@ -75,6 +75,7 @@ static inline bool cpu_has(unsigned int #define cpu_has_smx cpu_has(X86_FEATURE_SMX) #define cpu_has_pcidcpu_has(X8

Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

On Fri, Jan 20, 2017 at 07:45:35PM +, Andrew Cooper wrote: > On 19/01/17 17:29, Roger Pau Monne wrote: > > @@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy( > > { > > static unsigned long lastpage; > > if ( xchg(&lastpage, gfn) != gfn )

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > > Hi, > > > > > > I am sending twelfth version of multiboot2 protocol support for > > > legacy BIOS and EFI platforms. This

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

On 23/01/17 12:58, Roger Pau Monne wrote: > On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote: >> On 19/01/17 17:29, Roger Pau Monne wrote: >>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c >>> index 0ccef1d..f52f269 100644 >>> --- a/xen/arch/x86/setup.c >>> +++ b/xen/arch/x8

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote: > On 19/01/17 17:29, Roger Pau Monne wrote: > > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > > index 0ccef1d..f52f269 100644 > > --- a/xen/arch/x86/setup.c > > +++ b/xen/arch/x86/setup.c > > @@ -1545,6 +1545,15 @@ void __i

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

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

Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support

On Mon, Jan 23, 2017 at 01:34:21PM +0100, Juergen Gross wrote: > On 23/01/17 13:14, Wei Liu wrote: > > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote: > >> XS_RESTRICT and the xenstore library function xs_restrict() have never > >> been usable in all configurations and there are no k

Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support

On 23/01/17 13:14, Wei Liu wrote: > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote: >> XS_RESTRICT and the xenstore library function xs_restrict() have never >> been usable in all configurations and there are no known users. >> >> This functionality was thought to limit access rights

  1   2   >