[Xen-devel] [linux-3.18 test] 111191: regressions - FAIL

flight 91 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 110441

Re: [Xen-devel] [PATCH v12 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

On 17-06-29 12:00:12, Jan Beulich wrote: > >>> Yi Sun 06/14/17 3:25 AM >>> > > +struct cos_write_info > > +{ > > +unsigned int cos; > > +struct feat_node *feature; > > +uint32_t *val; > > const? > The member of feature, 'cos_reg_val', will be written in

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

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

[Xen-devel] [qemu-mainline test] 111177: tolerable trouble: broken/fail/pass - PUSHED

flight 77 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/77/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-xsm 4 host-install(4) broken in 42 pass in 77 test-armhf-armhf-xl-vhd

[Xen-devel] [PATCH 0/2] Add support parse PCI iommu bindings for Xen SMMU

The legacy IOMMU bindings will be deprecated in future. Instead, device tree provide generic IOMMU bindings and PCI IOMMU bindings. Currently, the PCI support hasn't been enabled on ARM Xen. So in this series, we just add the support of parsing PCI IOMMU bindings. Wei Chen (2): xen: devicetree:

[Xen-devel] [PATCH 1/2] xen: devicetree: Introduce a helper to translate PCI requester ID

Each PCI(e) device under a root complex is uniquely identified by its Requester ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and Function number. IOMMUs may distinguish PCI devices through sideband data derived from the Requester ID. While a given PCI device can only

[Xen-devel] [PATCH 2/2] xen/arm: smmu: Parse generic iommu binding for PCI devices

The legacy smmu binding will be deprecated in favour of the generic "iommus" binding. So we need a new helper to parse generic iommu bindings. When the system detects the SMMU is using generic iommu binding, this helper will be called when this platform device is assiged to a guest. This patch is

[Xen-devel] [PATCH 4/7] xen/arm: SMMU: Detect types of device tree binding

The device tree provides two types of IOMMU bindings, one is legacy another is generic. The legacy bindings will be depercated in favour of the generic bindings. But in the transitional period, we have to support both of them. The codes to handle these two types of bindings are very differnet, so

[Xen-devel] [PATCH 1/7] xen/arm: SMMU: Implement the add_device callback in SMMU

This add_device callback function is taking care of adding a device to SMMU and make sure it is fully prepare to be used by the SMMU afterwards. In previous code, we don't implement the add_device callback in iommu_ops for ARM SMMU. We placed the work of add_device to assign_device callback. The

[Xen-devel] [PATCH 6/7] xen/arm: SMMU: Support generic IOMMU bindings

The SMMU MasterIDs are placed at the master devices' DT node while using the generic bindings. In this case, it's very hard for us to register SMMU masters while probing SMMU as we had done for legacy bindings. Because we have to go through whole device tree for all SMMU devices to find their

[Xen-devel] [PATCH 2/7] xen/arm: SMMU: Introduce a helper to add DT device to SMMU

In current code, we only have the iommu_add_device to add PCI device to IOMMU. But for ARM SMMU, we don't have a separate helper to add platform device with device tree to SMMU. This work was included in the iommu_assign_dt_device. But sometimes, we just want to add device to SMMU to do some

[Xen-devel] [PATCH 3/7] xen/arm: Prepare SMMU resources for protected devices

In previous code, while we are constructing Dom0, we will assign all devices except passthrough devices to Dom0. In the later, when we start the DomU, the assign_device will prepare SMMU resources for the devices passthrough to DomU. This is ok when we kept the add_device code in assign_device.

[Xen-devel] [PATCH 7/7] xen: Fix a typo in error message of iommu_do_dt_domctl

It's a error message about XEN_DOMCTL_deassign_device, but the print message is XEN_DOMCTL_assign_device. Signed-off-by: Wei Chen --- xen/drivers/passthrough/device_tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [PATCH 0/7] Generic IOMMU bindings support for Xen platform devices

The "mmu-masters" is a property of ARM legacy SMMU dt-binding. This property will be deprecated in favour of the generic IOMMU bindings. In this case we have to add the generic IOMMU bindings support for Xen platform devices. --- This series has been tested on Seattle SoftIron server. The

[Xen-devel] [PATCH 5/7] xen/arm: SMMU: Keep registering legacy master in SMMU probe

The legacy IOMMU bindings place the SMMU MasterIDs in the SMMU device tree node. In current code, we register the SMMU masters while probing SMMU. It's better to keep registering legacy masters in the SMMU probing progress. If we move registering legacy SMMU masters to add_device or assign_device,

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

flight 71 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/71/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 10 debian-di-install fail REGR. vs. 111061 Tests which did not

[Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0), we would wrongly use 00:00.0 to search VT-d unit. From SRIOV spec REV 1.0 section 3.7.3, it says: "ARI is not applicable to Root Complex integrated Endpoints; all other SR-IOV Capable Devices (Devices that include at least

Re: [Xen-devel] [PATCH v3] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

On Thu, Jun 29, 2017 at 04:42:33PM +0100, Roger Pau Monné wrote: >On Thu, Jun 29, 2017 at 11:21:53AM +0800, Chao Gao wrote: >> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0), >> we would wrongly use 00:00.0 to search VT-d unit. >> >> From SRIOV spec REV 1.0 section 3.7.3,

Re: [Xen-devel] [PATCH v2 0/2] libxl: cpuid bits

On Wed, Jun 28, 2017 at 06:55:58PM +0100, Wei Liu wrote: > On Wed, Jun 28, 2017 at 12:10:20PM +0200, Marek Marczykowski-Górecki wrote: > > This adds handling more cpuid bits by name. Mostly based on cpu_map.xml from > > libvirt. > > > > Marek Marczykowski-Górecki (2): > > libxl: add more cpuid

[Xen-devel] [xtf test] 111193: regressions - trouble: broken/pass

flight 93 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 59 leak-check/check fail REGR. vs. 111074 test-xtf-amd64-amd64-3

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

Hello Dario, On 30 June 2017 at 00:26, Dario Faggioli wrote: > On Thu, 2017-06-29 at 22:04 +0300, Volodymyr Babchuk wrote: >> Hello all, >> > Hello, > >> 1. OP-TEE use case: DRM playback (secure data path). >> >> User wants to play a DRM-protected media file. Rights

[Xen-devel] [ovmf baseline-only test] 71616: tolerable FAIL

This run is configured for baseline tests only. flight 71616 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71616/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-libvirt5 libvirt-build

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

flight 68 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/68/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 110465

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

On Thu, 2017-06-29 at 22:04 +0300, Volodymyr Babchuk wrote: > Hello all, > Hello, > 1. OP-TEE use case: DRM playback (secure data path). > > User wants to play a DRM-protected media file. Rights holders don't > want to give user any means to get DRM-free copy of that media file. > If you ever

Re: [Xen-devel] q35 support in Xen

On Fri, 30 Jun 2017, Alexey G wrote: > Hi, > > > I saw Anthony's patch, but your extension patch seems still in > > development. Do you have plan to upstream it? I'm also interested in > > this basically I want full PCI-e passthru capability (Current Xen does > > support passthru a PCI-e device

Re: [Xen-devel] q35 support in Xen

Hi, > I saw Anthony's patch, but your extension patch seems still in > development. Do you have plan to upstream it? I'm also interested in > this basically I want full PCI-e passthru capability (Current Xen does > support passthru a PCI-e device but guest can't see configuration offset >

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

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

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

On June 29, 2017 11:40:30 AM PDT, Oleksandr Andrushchenko wrote: >Hi, Dmitry! > >First of all thank you for both the comments and the patch > >On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: >> Hi Oleksandr, >> >> On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

Hello all, Thank you all for the call. As was agreed, I'll to provide some details on our use cases. I want to tell you about four cases: one is OP-TEE related, while other three shows various aspects of virtualized coprocesssors workflow. 1. OP-TEE use case: DRM playback (secure data path).

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

Hi, Dmitry! First of all thank you for both the comments and the patch On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: Hi Oleksandr, On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko wrote: + switch (event->mtouch.event_type) { +

Re: [Xen-devel] [PATCH v12 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

>>> Yi Sun 06/14/17 3:25 AM >>> > +struct cos_write_info > +{ > +unsigned int cos; > +struct feat_node *feature; > +uint32_t *val; const? > static int write_psr_msrs(unsigned int socket, unsigned int cos, >uint32_t val[],

Re: [Xen-devel] [PATCH v12 11/23] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

>>> Yi Sun 06/14/17 3:25 AM >>> > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -845,12 +845,97 @@ static int find_cos(const uint32_t val[], unsigned int > array_len, > return -ENOENT; > } > > +static bool fits_cos_max(const uint32_t val[], > +

Re: [Xen-devel] [PATCH v12 10/23] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

>>> Yi Sun 06/14/17 3:25 AM >>> > static int find_cos(const uint32_t val[], unsigned int array_len, > enum psr_feat_type feat_type, > const struct psr_socket_info *info) > { > +unsigned int cos, cos_max; > +const

Re: [Xen-devel] [PATCH v12 09/23] x86: refactor psr: L3 CAT: set value: assemble features value array.

>>> Yi Sun 06/14/17 3:25 AM >>> > @@ -592,7 +615,14 @@ int psr_get_val(struct domain *d, unsigned int socket, > /* Set value functions */ > static unsigned int get_cos_num(const struct psr_socket_info *info) > { > -return 0; > +unsigned int num = 0, i; > + > +

Re: [Xen-devel] [PATCH 3/6] libxc: Add wrappers for new commands

On Tue, Jun 27, 2017 at 12:14:55PM -0500, Venu Busireddy wrote: > libxc: Add wrappers for new commands Extraneous line here. > > Add wrappers for the newly introduced commands "pci-assignable-hide", > "pci-assignable-unhide", and "pci-assignable-list-hidden". > > Signed-off-by: Venu Busireddy

[Xen-devel] New Design Sessions for the Developer Summit

Hi all, (proposers CC'ed) I added several new design sessions today: people on the CC list may want to propose different time-slots * https://xendeveloperanddesignsummit2017.sched.com/event/AjEI/design-session-the-missing-toolstack-side-of-pvh-domu *

Re: [Xen-devel] [PATCH v3 00/11] libxl: add PV display device driver interface

Can you push this series to a git tree? It would be easier for me to check your changes to the device framework. The device specific handlers mostly look OK to me. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 01/11] libxl: add vdispl structures to idl

On Tue, Jun 27, 2017 at 01:03:17PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Add libxl_device_vdispl and libxl_vdisplinfo to libxl_types.idl > Add VDISPL to libxl__device_kind enumerator > > Signed-off-by: Oleksandr Grytsov

Re: [Xen-devel] [PATCH v3 11/11] docs: add PV display driver information

On Tue, Jun 27, 2017 at 01:03:27PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov > --- > docs/man/xl.cfg.pod.5.in | 54 > >

Re: [Xen-devel] [PATCH v3 04/11] libxl: add generic function to add device

On Tue, Jun 27, 2017 at 01:03:20PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Add libxl__device_add functio. function > Almost all devices have similar libxl__device__add function. > This generic function implements same functionality but >

Re: [Xen-devel] [PATCH v3 03/11] libxl: add generic function to get and free device list

On Tue, Jun 27, 2017 at 01:03:19PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Add libxl__device_list, libxl__device_list_free. > Device list is created from libxl xen store entries. > In order to fill libxl device structure from xen store, > the

[Xen-devel] [xen-4.9-testing test] 111162: regressions - FAIL

flight 62 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 31

Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce {G, M}FN_INVALID_INITIALIZER

On 29/06/17 17:30, Julien Grall wrote: > Hi, > > On 06/27/2017 10:47 AM, Julien Grall wrote: >> >> >> On 27/06/2017 10:46, Tim Deegan wrote: >>> At 10:33 +0100 on 27 Jun (1498559600), Julien Grall wrote: The current implementation of {G,M}FN_INVALID cannot be used to initialize global

Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce {G, M}FN_INVALID_INITIALIZER

Hi, On 06/27/2017 10:47 AM, Julien Grall wrote: On 27/06/2017 10:46, Tim Deegan wrote: At 10:33 +0100 on 27 Jun (1498559600), Julien Grall wrote: The current implementation of {G,M}FN_INVALID cannot be used to initialize global variable because the initializer element is not a constant.

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

On Thu, Jun 29, 2017 at 03:34:37PM +0100, Roger Pau Monné wrote: > On Thu, Jun 29, 2017 at 02:56:55PM +0100, Wei Liu wrote: > > On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote: > > > Thanks Wei. Currently it is started after the memory is streamed from > > > source to destination

Re: [Xen-devel] [PATCH for-4.9 v2] livepatch: Declare live patching as a supported feature

>>> Julien Grall 06/29/17 4:31 PM >>> >On 06/29/2017 07:47 AM, Jan Beulich wrote: > Ross Lagerwall 06/28/17 6:14 PM >>> >>> --- a/xen/common/Kconfig >>> +++ b/xen/common/Kconfig >>> @@ -226,7 +226,7 @@ config CRYPTO >> >bool >> > >>

Re: [Xen-devel] [PATCH v3] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

On Thu, Jun 29, 2017 at 11:21:53AM +0800, Chao Gao wrote: > The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0), > we would wrongly use 00:00.0 to search VT-d unit. > > From SRIOV spec REV 1.0 section 3.7.3, it says: > "ARI is not applicable to Root Complex integrated

Re: [Xen-devel] Containing unrecoverable AER errors...

On 2017-06-20 12:56:34 +0100, Wei Liu wrote: > On Wed, Jun 07, 2017 at 02:24:32PM -0500, Venu Busireddy wrote: > > > > Hi, > > > > I am working on creating a patch to aid in containing the unrecoverable > > AER errors generated by PCI devices assigned to guests in passthrough > > mode. > > > >

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

Hi Julien, My thoughts are that while it is not essential to recover from AER and DPC initially, it is critical to at least take the slot offline and notify drivers so they quiesce. Without this basic handling, it is possible to create backups in some hardware that result in CPU hangs for

[Xen-devel] [ovmf baseline-only test] 71615: regressions - FAIL

This run is configured for baseline tests only. flight 71615 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71615/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

On Thu, Jun 29, 2017 at 02:56:55PM +0100, Wei Liu wrote: > On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote: > > Thanks Wei. Currently it is started after the memory is streamed from > > source to destination (for migration) and the booting functions are > > completed.I was going to

Re: [Xen-devel] [PATCH for-4.9 v2] livepatch: Declare live patching as a supported feature

Hi, On 06/29/2017 07:47 AM, Jan Beulich wrote: Ross Lagerwall 06/28/17 6:14 PM >>> --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -226,7 +226,7 @@ config CRYPTO >bool > >config LIVEPATCH - bool "Live patching support (TECH PREVIEW)" +

[Xen-devel] [xtf test] 111180: regressions - trouble: broken/pass

flight 80 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/80/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 59 leak-check/check fail REGR. vs. 111074 test-xtf-amd64-amd64-4

[Xen-devel] [xen-unstable-smoke test] 111187: tolerable trouble: broken/pass - PUSHED

flight 87 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/87/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13

[Xen-devel] [linux-3.18 test] 111155: regressions - trouble: blocked/broken/fail/pass

flight 55 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/55/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine 4 host-install broken REGR. vs. 110441 build-armhf-pvops

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

On Thu, Jun 29, 2017 at 09:33:07AM -0400, Bruno Alvisio wrote: > Thanks Wei. Currently it is started after the memory is streamed from > source to destination (for migration) and the booting functions are > completed.I was going to ask to the list if there is a specific reason the > QEMU process

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

Thanks Wei. Currently it is started after the memory is streamed from source to destination (for migration) and the booting functions are completed.I was going to ask to the list if there is a specific reason the QEMU process needs to be started at that point. Also, if the start point of the QEMU

Re: [Xen-devel] q35 support in Xen

> Anthony Perard did a great job providing patches which add a partial > Q35 > support. I tried extending his patches to include missing features for > Q35 in > hvmloader, libacpi and QEMU and so far the Xen+Q35 experience is quite > positive Hi Alexey,  I saw Anthony's patch, but your

Re: [Xen-devel] [xtf test] 111167: regressions - trouble: broken/pass

On 29/06/17 09:54, osstest service owner wrote: > flight 67 xtf real [real] > http://logs.test-lab.xenproject.org/osstest/logs/67/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-xtf-amd64-amd64-1 59

[Xen-devel] livepatch-tools: Handle new files in patch sets

Reference: https://xenproject.atlassian.net/browse/XEN-90 If you create a Xen patch for livepatch that adds additional files to the build (adds the files and patches the Makefile to include them), the livepatch tools (from https://github.com/rosslagerwall/livepatch-build-tools) do not properly

Re: [Xen-devel] [PATCH v4 08/11] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

On Mon, Jun 26, 2017 at 05:16:22PM +0800, Haozhong Zhang wrote: > If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present > in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP. > By default, LMCE is not exposed to guest so as to keep the backwards migration >

[Xen-devel] [PATCH 5/5] tools: tracing: handle null scheduler's events

In both xentrace and xenalyze. Signed-off-by: Dario Faggioli --- George Dunlap --- tools/xentrace/formats|7 + tools/xentrace/xenalyze.c | 65 + 2 files changed, 72 insertions(+)

[Xen-devel] [PATCH 4/5] xen: sched_null: add some tracing

In line with what is there in all the other schedulers. Signed-off-by: Dario Faggioli --- George Dunlap --- xen/common/sched_null.c| 94 +++- xen/include/public/trace.h |1 2 files

[Xen-devel] [PATCH 2/5] xen: sched_null: check for pending tasklet work a bit earlier

Whether or not there's pending tasklet work to do, it's something we know from the tasklet_work_scheduled parameter. Deal with that as soon as possible, like all other schedulers do. Signed-off-by: Dario Faggioli --- Cc: George Dunlap ---

[Xen-devel] [PATCH 3/5] xen: sched-null: support soft-affinity

The null scheduler does not really use hard-affinity for scheduling, it uses it for 'placement', i.e., for deciding to what pCPU to statically assign a vCPU. Let's use soft-affinity in the same way, of course with the difference that, if there's no free pCPU within the vCPU's soft-affinity, we go

[Xen-devel] [PATCH 1/5] xen: sched: factor affinity helpers out of sched_credit.c

In fact, we want to be able to use them from any scheduler. While there, make the moved code use 'v' for struct_vcpu* variable, like it should be done everywhere. No functional change intended. Signed-off-by: Dario Faggioli Signed-off-by: Justin T. Weaver

[Xen-devel] [PATCH 0/5] xen: sched_null: support soft affinity

In the null scheduler, we don't need either hard or soft affinity during online scheduling operations. In fact, the vCPUs are statically assigned to the pCPUs, and hence there's no scope for checking or enforcing any affinity. We, however, use hard-affinity for 'placement', i.e., for deciding to

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

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

Re: [Xen-devel] [PATCH 0/3] please pull xen-20170627-tag

On 27 June 2017 at 23:04, Stefano Stabellini wrote: > The following changes since commit 577caa2672ccde7352fda3ef17e44993de862f0e: > > Merge remote-tracking branch > 'remotes/edgar/tags/edgar/mmio-exec-v2.for-upstream' into staging (2017-06-27 > 16:56:55 +0100) > > are

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

On Fri, Jun 23, 2017 at 03:42:20AM -0400, Bruno Alvisio wrote: > This patch is the first attempt on adding live migration of instances with > local > storage to Xen. This patch just handles very restricted case of fully > virtualized HVMs. The code uses the "drive-mirror" capability provided by

[Xen-devel] [PATCH 24/25] x86/vvtd: Add queued invalidation (QI) support

From: Chao Gao Queued Invalidation Interface is an expanded invalidation interface with extended capabilities. Hardware implementations report support for queued invalidation interface through the Extended Capability Register. The queued invalidation interface uses an

[Xen-devel] [PATCH 21/25] Tools/libxc: Add a new interface to bind remapping format msi with pirq

From: Chao Gao Introduce a new binding relationship and provide a new interface to manage the new relationship. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- tools/libxc/include/xenctrl.h | 17 ++

[Xen-devel] [PATCH 25/25] x86/vvtd: save and restore emulated VT-d

From: Chao Gao Wrap some useful status in a new structure hvm_hw_vvtd, following the customs of vlapic, vioapic and etc. Provide two save-restore pairs to save/restore registers and non-register status. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu

[Xen-devel] [PATCH 7/25] Tools/libacpi: Add DMA remapping reporting (DMAR) ACPI table structures

From: Chao Gao Add dmar table structure according Chapter 8 "BIOS Considerations" of VTd spec Rev. 2.4. VTd spec:http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf Signed-off-by: Chao Gao

[Xen-devel] [PATCH 15/25] x86/vvtd: decode interrupt attribute from IRTE

From: Chao Gao Previously, interrupt attributes can be extracted from msi message or IOAPIC RTE. However, with interrupt remapping enabled, the attributes are enclosed in the associated IRTE. This callback is for cases in which the caller wants to acquire interrupt

[Xen-devel] [PATCH 10/25] libxl: create vIOMMU during domain construction

From: Chao Gao If guest is configured to have a vIOMMU, create it during domain construction. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- tools/libxl/libxl_arch.h | 5 + tools/libxl/libxl_arm.c| 7 +++

[Xen-devel] [PATCH 23/25] x86/vvtd: Handle interrupt translation faults

From: Chao Gao Interrupt translation faults are non-recoverable fault. When faults are triggered, it needs to populate fault info to Fault Recording Registers and inject vIOMMU msi interrupt to notify guest IOMMU driver to deal with faults. This patch emulates hardware's

[Xen-devel] [PATCH 20/25] passthrough: move some fields of hvm_gmsi_info to a sub-structure

From: Chao Gao No functional change. It is a preparation for introducing new fields in hvm_gmsi_info to manage remapping format msi bound to a physical msi. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu ---

[Xen-devel] [PATCH 17/25] X86/vvtd: Enable Queued Invalidation through GCMD

From: Chao Gao Software writes to QIE fields of GCMD to enable or disable queued invalidations. This patch emulates QIE fields of GCMD. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/drivers/passthrough/vtd/iommu.h | 3

[Xen-devel] [PATCH 13/25] X86/vvtd: Set Interrupt Remapping Table Pointer through GCMD

From: Chao Gao Software sets this field to set/update the interrupt remapping table pointer used by hardware. The interrupt remapping table pointer is specified through the Interrupt Remapping Table Address (IRTA_REG) register. This patch emulates this operation and adds

[Xen-devel] [PATCH 14/25] X86/vvtd: Process interrupt remapping request

From: Chao Gao When a remapping interrupt request arrives, remapping hardware computes the interrupt_index per the algorithm described in VTD spec "Interrupt Remapping Table", interprets the IRTE and generates a remapped interrupt request. This patch introduces

[Xen-devel] [PATCH 19/25] x86/vioapic: introduce a function to get vector from pin

From: Chao Gao When IOAPIC RTE is in remapping format, it doesn't contain the vector of interrupt. This patch adds vioapic_pin_vector() to get vector from pin for both remapping format and legacy format and uses this function other than accessing IOAPIC RTE directly.

[Xen-devel] [PATCH 16/25] x86/vioapic: Hook interrupt delivery of vIOAPIC

From: Chao Gao When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping format. If that, generate an irq_remapping_request and call the common VIOMMU abstraction's callback to handle this interrupt request. Device model is responsible for checking the

[Xen-devel] [PATCH 22/25] x86/vmsi: Hook delivering remapping format msi to guest

From: Chao Gao In two situations, hypervisor delivers a msi to a hvm guest. One is when qemu sends a request to hypervisor through XEN_DMOP_inject_msi. The other is when a physical interrupt arrives and it has been bound to a guest msi. For the former, the msi is routed to

[Xen-devel] [PATCH 18/25] X86/vvtd: Enable Interrupt Remapping through GCMD

From: Chao Gao Software writes this field to enable/disable interrupt reampping. This patch emulate IRES field of GCMD. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/drivers/passthrough/vtd/iommu.h | 3 ++-

[Xen-devel] [PATCH 12/25] X86/vvtd: Add MMIO handler for VVTD

From: Chao Gao This patch adds VVTD MMIO handler to deal with MMIO access. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/drivers/passthrough/vtd/vvtd.c | 114 + 1 file changed, 114

[Xen-devel] [PATCH 3/25] VIOMMU: Add irq request callback to deal with irq remapping

This patch is to add irq request callback for platform implementation to deal with irq remapping request. Signed-off-by: Lan Tianyu --- xen/common/viommu.c | 15 + xen/include/asm-x86/viommu.h | 73

[Xen-devel] [PATCH 6/25] Tools/libxc: Add viommu operations in libxc

From: Chao Gao This patch is to add XEN_DOMCTL_viommu_op hypercall. This hypercall comprise three sub-command: - query capabilities of one specific type vIOMMU emulated by Xen - create vIOMMU in Xen hypervisor with viommu type, register range, capability - destroy vIOMMU

[Xen-devel] [PATCH 2/25] DOMCTL: Introduce new DOMCTL commands for vIOMMU support

This patch is to introduce create, destroy and query capabilities command for vIOMMU. vIOMMU layer will deal with requests and call arch vIOMMU ops. Signed-off-by: Lan Tianyu --- xen/common/domctl.c | 3 +++ xen/common/viommu.c | 43

[Xen-devel] [PATCH 11/25] x86/hvm: Introduce a emulated VTD for HVM

From: Chao Gao This patch adds create/destroy/query function for the emulated VTD and adapts it to the common VIOMMU abstraction. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/drivers/passthrough/vtd/Makefile | 7 +-

[Xen-devel] [PATCH 9/25] Tools/libacpi: Add a user configurable parameter to control vIOMMU attributes

From: Chao Gao a field, viommu_info, is added to struct libxl_domain_build_info. Several attributes can be specified by guest configuration file for the DMAR table building and vIOMMU creation. In domain creation process, a new logic is added to build ACPI DMAR table in tool

[Xen-devel] [PATCH 4/25] VIOMMU: Add get irq info callback to convert irq remapping request

This patch is to add get_irq_info callback for platform implementation to convert irq remapping request to irq info (E,G vector, dest, dest_mode and so on). Signed-off-by: Lan Tianyu --- xen/common/viommu.c | 16 xen/include/asm-x86/viommu.h | 8

[Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

This patch is to add Xen virtual IOMMU doc to introduce motivation, framework, vIOMMU hypercall and xl configuration. Signed-off-by: Lan Tianyu --- docs/misc/viommu.txt | 129 +++ 1 file changed, 129 insertions(+) create

[Xen-devel] [PATCH 1/25] VIOMMU: Add vIOMMU helper functions to create, destroy and query capabilities

This patch is to introduct an abstract layer for arch vIOMMU implementation to deal with requests from dom0. Arch vIOMMU code needs to provide callback to perform create, destroy and query capabilities operation. Signed-off-by: Lan Tianyu --- xen/arch/x86/setup.c|

[Xen-devel] [PATCH 8/25] Tools/libacpi: Add new fields in acpi_config to build DMAR table

From: Chao Gao The BIOS reports the remapping hardware units in a platform to system software through the DMA Remapping Reporting (DMAR) ACPI table. To build DMAR table during domain construction, two fields are added to struct acpi_config. One is dmar_flag which indicates

[Xen-devel] [PATCH 00/25] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion of virtual vtd

Change since RFC v2: 1) Move vvtd.c to drivers/passthrough/vtd directroy. 2) Make vIOMMU always built in on x86 3) Add new boot cmd "viommu" to enable viommu function 4) Fix some code stype issues. Change since RFC v1: 1) Add Xen virtual IOMMU doc

[Xen-devel] [PATCH 3/3] msi: Handle remappable format interrupt request

From: Chao Gao According to VT-d spec Interrupt Remapping and Interrupt Posting -> Interrupt Remapping -> Interrupt Request Formats On Intel 64 Platforms, fields of MSI data register have changed. This patch avoids wrongly regarding a remappable format interrupt request as an

[Xen-devel] [PATCH 2/3] xen-pt: bind/unbind interrupt remapping format MSI

From: Chao Gao If a vIOMMU is exposed to guest, guest will configure the msi to remapping format. The original code isn't suitable to the new format. A new pair bind/unbind interfaces are added for this usage. This patch recognizes this case and uses new interfaces to

[Xen-devel] [PATCH 0/3] Qemu: Add Xen vIOMMU interrupt remapping function support

This patchset is to deal with MSI interrupt remapping request when guest updates MSI registers. Chao Gao (3): i386/msi: Correct mask of destination ID in MSI address xen-pt: bind/unbind interrupt remapping format MSI msi: Handle remappable format interrupt request configure

[Xen-devel] [PATCH 1/3] i386/msi: Correct mask of destination ID in MSI address

From: Chao Gao According to SDM 10.11.1, only [19:12] bits of MSI address are Destination ID, change the mask to avoid ambiguity for VT-d spec has used the bit 4 to indicate a remappable interrupt request. Signed-off-by: Chao Gao Signed-off-by: Lan

  1   2   >