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

flight 106747 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/106747/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 106732 test-armhf-armhf-libvirt

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

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

[Xen-devel] [linux-linus test] 106744: regressions - FAIL

flight 106744 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106744/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254

[Xen-devel] [linux-next test] 106743: regressions - FAIL

flight 106743 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/106743/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 106570

Re: [Xen-devel] [PATCH 2/3] Introduce the Xen 9pfs transport header

On Fri, 17 Mar 2017, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 14, 2017 at 03:18:35PM -0700, Stefano Stabellini wrote: > > Define the ring according to the protocol specification, using the new > > DEFINE_XEN_FLEX_RING_AND_INTF macro. > > > > There is a bit of 9pfs code being posted. Is this

Re: [Xen-devel] [PATCH 3/3] Introduce the pvcalls header

On Fri, 17 Mar 2017, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 14, 2017 at 03:18:36PM -0700, Stefano Stabellini wrote: > > Define the ring and request and response structs according to the > > specification. Use the new DEFINE_XEN_FLEX_RING macro. > > Don't want to copy-n-paste some of the

Re: [Xen-devel] [PATCH 1/3] [RESEND v4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

On Fri, 17 Mar 2017, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 14, 2017 at 03:18:34PM -0700, Stefano Stabellini wrote: > > This patch introduces macros, structs and functions to handle rings in > > the format described by docs/misc/pvcalls.markdown and > > docs/misc/9pfs.markdown. The index page

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On Fri, 17 Mar 2017, Paolo Bonzini wrote: > On 17/03/2017 12:29, Lan Tianyu wrote: > > This patchset is to add Xen vIOMMU device model and handle > > irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor > > and the new device module in Qemu works as hypercall wrappers to > > create

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

On Fri, 17 Mar 2017, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 17, 2017 at 05:54:47AM +0100, Juergen Gross wrote: > > On 16/03/17 19:03, Stefano Stabellini wrote: > > > On Thu, 16 Mar 2017, Juergen Gross wrote: > > >> On 15/03/17 19:44, Stefano Stabellini wrote: > > >>> On Wed, 15 Mar 2017,

[Xen-devel] [xen-4.8-testing test] 106738: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 106738 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106738/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 106728 test-amd64-i386-libvirt

[Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler

It being very very basic, also means this scheduler does not need much support at the tools level (for now). Basically, just the definition of the symbol of the scheduler itself and a couple of stubs. Signed-off-by: Dario Faggioli --- Cc: Wei Liu

[Xen-devel] [PATCH 2/3] xen: sched_null: support for hard affinity

As a (rudimental) way of directing and affecting the placement logic implemented by the scheduler, support vCPU hard affinity. Basically, a vCPU will now be assigned only to a pCPU that is part of its own hard affinity. If such pCPU(s) is (are) busy, the vCPU will wait, like it happens when there

[Xen-devel] [PATCH 0/3] The 'null' Scheduler

Hello, This patch series implements what I call the 'null' scheduler. It's a very simple, very static scheduling posicy that always schedules the same vCPU(s) on the same pCPU(s). That's it. If there are less vCPUs than pCPUs, some of the pCPUs are _always_ idle. If there are more, some vCPUs

[Xen-devel] [PATCH 1/3] xen: sched: introduce the 'null' semi-static scheduler

In cases where one is absolutely sure that there will be less vCPUs than pCPUs, having to pay the cose, mostly in terms of overhead, of an advanced scheduler may be not desirable. The simple scheduler implemented here could be a solution. Here how it works: - each vCPU is statically assigned to

Re: [Xen-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

On Fri, 17 Mar 2017, Juergen Gross wrote: > On 16/03/17 21:20, Stefano Stabellini wrote: > > On Thu, 16 Mar 2017, Juergen Gross wrote: > >> Instead of trying to guess the Xen version to use by compiling various > >> test programs first just ask the system via pkg-config. Only if it > >> can't

Re: [Xen-devel] [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

On 17/03/17 19:19, Dario Faggioli wrote: > Within context_saved(), we call the context_saved hook, > and we use VCPU2OP() to determine from what scheduler. > VCPU2OP uses DOM2OP, which uses d->cpupool, which is > NULL when d is the idle domain. And in that case, > DOM2OP just returns ops, the

Re: [Xen-devel] [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

On 17/03/17 19:19, Dario Faggioli wrote: > Within context_saved(), we call the context_saved hook, > and we use VCPU2OP() to determine from what scheduler. > VCPU2OP uses DOM2OP, which uses d->cpupool, which is > NULL when d is the idle domain. And in that case, > DOM2OP just returns ops, the

[Xen-devel] [xen-unstable test] 106737: regressions - trouble: blocked/broken/fail/pass

flight 106737 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106737/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl3 host-install(3)broken REGR. vs. 106652

[Xen-devel] [PATCH v2 2/2] xen: sched: improve robustness (and rename) DOM2OP()

Clarify and enforce (with ASSERTs) when the function is called on the idle domain, and explain in comments what it means and when it is ok to do so. While there, change the name of the function to a more self-explanatory one, and do the same to VCPU2OP. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH v2 1/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

Within context_saved(), we call the context_saved hook, and we use VCPU2OP() to determine from what scheduler. VCPU2OP uses DOM2OP, which uses d->cpupool, which is NULL when d is the idle domain. And in that case, DOM2OP just returns ops, the scheduler of cpupool0. Therefore, if: - cpupool0's

[Xen-devel] [PATCH v2 0/2] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

Hi, This is v2 of https://lists.xen.org/archives/html/xen-devel/2017-03/msg02119.html It's now two patches. Patch 1 is what I already sent, amended taking into account Jan's suggesions. It is the actual bugfix and the one that should be backported. Patch 2 is basically applying the same

Re: [Xen-devel] [PATCH v3 7/9] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

On Fri, 17 Mar 2017, Greg Kurz wrote: > On Thu, 16 Mar 2017 13:01:56 -0700 > Stefano Stabellini wrote: > > > Implement xen_9pfs_init_in/out_iov_from_pdu and > > xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the > > data on the ring. > > > > This is

[Xen-devel] [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal

Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and host frequencies are the same") left out optimization for PV guests when host and guest run at the same frequency. For such a case we should be able not to use virtual TSC regardless of whether we are runing before or after a

Re: [Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

On Fri, 17 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 03/17/2017 06:51 AM, Wei Chen wrote: > > Hi Stefano, > > > > On 2017/3/17 7:17, Stefano Stabellini wrote: > > > On Thu, 16 Mar 2017, Julien Grall wrote: > > > > On 03/16/2017 10:40 PM, Stefano Stabellini wrote: > > > > > On Wed, 15 Mar

Re: [Xen-devel] [PATCH v3 5/9] xen/9pfs: connect to the frontend

On Fri, 17 Mar 2017, Greg Kurz wrote: > On Thu, 16 Mar 2017 13:01:54 -0700 > Stefano Stabellini wrote: > > > Write the limits of the backend to xenstore. Connect to the frontend. > > Upon connection, allocate the rings according to the protocol > > specification. > > > >

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

flight 106748 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106748/ 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 build-arm64-pvops 5

Re: [Xen-devel] [PATCH v3 1/9] xen: do not build backends for targets that do not support xen

On Fri, 17 Mar 2017, Paolo Bonzini wrote: > On 16/03/2017 21:01, Stefano Stabellini wrote: > > Change Makefile.objs to use CONFIG_XEN instead of CONFIG_XEN_BACKEND, so > > that the Xen backends are only built for targets that support Xen. > > > > Set CONFIG_XEN in the toplevel Makefile to ensure

[Xen-devel] MiniOS aarch64 support

Hello all, I want to share my patches for MiniOS, that enables it to work on ARM64 platforms. Initial work was done by Chen Baozi, many thanks to him. I just added context switching code and some logic to traps handler plus mapping xenbus page. You can find those patches at [1]. There are two

Re: [Xen-devel] [PATCH 08/18] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

On Fri, 17 Mar 2017, Wei Chen wrote: > Hi Stefano, > On 2017/3/17 7:30, Stefano Stabellini wrote: > > On Mon, 13 Mar 2017, Wei Chen wrote: > >> In the later patches of this series, we want to use the alternative > >> patching framework to avoid checking serror_op in every entries. > >> So we

Re: [Xen-devel] [PATCH v2 2/9] x86/pagewalk: Use pointer syntax for pfec parameter

>>> On 16.03.17 at 17:31, wrote: > It is a pointer, not an array. > > No functional change. > > Requested-by: Jan Beulich > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 1/9] x86/cpuid: Sort cpu_has_* predicates by feature number

>>> On 16.03.17 at 17:31, wrote: > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Wondering about cirris and stdvga

On March 17, 2017 11:51:03 AM EDT, Dario Faggioli wrote: >On Fri, 2017-03-17 at 10:19 -0400, Konrad Rzeszutek Wilk wrote: >> --- a/tools/libxl/libxl_create.c >> +++ b/tools/libxl/libxl_create.c >> @@ -225,7 +225,7 @@ int libxl__domain_build_info_setdefault(libxl__gc >>

[Xen-devel] [Intel-gfx] [Announcement] 2016-Q4 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi all, We are pleased to announce another update of Intel GVT-g for Xen. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with

Re: [Xen-devel] Wondering about cirris and stdvga

On Fri, 2017-03-17 at 10:19 -0400, Konrad Rzeszutek Wilk wrote: > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -225,7 +225,7 @@ int libxl__domain_build_info_setdefault(libxl__gc > *gc, >  if (b_info->device_model_version == > LIBXL_DEVICE_MODEL_VERSION_NONE)

Re: [Xen-devel] [PATCH 2/2] x86/EFI: avoid Xen image when looking for module/kexec position

On 17/03/17 15:16, Jan Beulich wrote: > When booting straight from EFI, we don't further try to relocate Xen. > As a result, so far we also didn't avoid the area Xen uses when looking > for a location to put modules or the kexec area. Introduce a fake > module slot to deal with that without having

Re: [Xen-devel] [PATCH 1/2] x86/EFI: avoid IOMMU faults on [_end, __2M_rwdata_end)

On 17/03/17 15:15, Jan Beulich wrote: > Commit c9a4a1c419 ("x86/layout: Correct Xen's idea of its own memory > layout") didn't go far enough with the conversion, causing IOMMU faults > when memory from that range was handed to a domain. We must not make > this memory available for allocation (the

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

On 03/17/2017 10:56 AM, Jan Beulich wrote: On 17.03.17 at 15:50, wrote: >> On 03/17/2017 10:24 AM, Jan Beulich wrote: >> On 17.03.17 at 14:36, wrote: On 03/17/2017 03:48 AM, Jan Beulich wrote: On 16.03.17 at 20:35,

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

>>> On 17.03.17 at 16:13, wrote: > On 03/17/2017 10:56 AM, Jan Beulich wrote: > On 17.03.17 at 15:50, wrote: >>> On 03/17/2017 10:24 AM, Jan Beulich wrote: >>> On 17.03.17 at 14:36, wrote: > On

[Xen-devel] [linux-4.1 test] 106733: regressions - trouble: blocked/broken/fail/pass

flight 106733 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/106733/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301 Tests which are

[Xen-devel] [PATCH 2/2] x86/EFI: avoid Xen image when looking for module/kexec position

When booting straight from EFI, we don't further try to relocate Xen. As a result, so far we also didn't avoid the area Xen uses when looking for a location to put modules or the kexec area. Introduce a fake module slot to deal with that without having to fiddle with a lot of code. Signed-off-by:

[Xen-devel] [PATCH 1/2] x86/EFI: avoid IOMMU faults on [_end, __2M_rwdata_end)

Commit c9a4a1c419 ("x86/layout: Correct Xen's idea of its own memory layout") didn't go far enough with the conversion, causing IOMMU faults when memory from that range was handed to a domain. We must not make this memory available for allocation (the change is benign to xen.gz at this point in

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

On Fri, Mar 17, 2017 at 05:54:47AM +0100, Juergen Gross wrote: > On 16/03/17 19:03, Stefano Stabellini wrote: > > On Thu, 16 Mar 2017, Juergen Gross wrote: > >> On 15/03/17 19:44, Stefano Stabellini wrote: > >>> On Wed, 15 Mar 2017, Juergen Gross wrote: > On 14/03/17 22:22, Stefano Stabellini

Re: [Xen-devel] [PATCH 1/3] [RESEND v4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

On Tue, Mar 14, 2017 at 03:18:34PM -0700, Stefano Stabellini wrote: > This patch introduces macros, structs and functions to handle rings in > the format described by docs/misc/pvcalls.markdown and > docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) > contains the indexes and the

Re: [Xen-devel] [PATCH 2/3] Introduce the Xen 9pfs transport header

On Tue, Mar 14, 2017 at 03:18:35PM -0700, Stefano Stabellini wrote: > Define the ring according to the protocol specification, using the new > DEFINE_XEN_FLEX_RING_AND_INTF macro. > There is a bit of 9pfs code being posted. Is this patch still up-to-date with that? I am going to assume yes, in

Re: [Xen-devel] [PATCH 3/3] Introduce the pvcalls header

On Tue, Mar 14, 2017 at 03:18:36PM -0700, Stefano Stabellini wrote: > Define the ring and request and response structs according to the > specification. Use the new DEFINE_XEN_FLEX_RING macro. Don't want to copy-n-paste some of the XenBus entries? Or at least point to them (the docs)? May I also

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

>>> On 17.03.17 at 15:50, wrote: > On 03/17/2017 10:24 AM, Jan Beulich wrote: > On 17.03.17 at 14:36, wrote: >>> On 03/17/2017 03:48 AM, Jan Beulich wrote: >>> On 16.03.17 at 20:35, wrote: > ---

[Xen-devel] [PATCH 0/2] x86/EFI: correct boot time memory accounting

1: avoid IOMMU faults on [_end,__2M_rwdata_end) 2: avoid Xen image when looking for module/kexec position Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

On 03/17/2017 10:24 AM, Jan Beulich wrote: On 17.03.17 at 14:36, wrote: >> On 03/17/2017 03:48 AM, Jan Beulich wrote: >> On 16.03.17 at 20:35, wrote: --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -2051,17

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 17/03/2017 12:29, Lan Tianyu wrote: > This patchset is to add Xen vIOMMU device model and handle > irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor > and the new device module in Qemu works as hypercall wrappers to > create and destroy vIOMMU in hypervisor. > > Xen only

Re: [Xen-devel] [PATCH 1/2] xen/arm32: Introduce alternative runtime patching

On Thu, Mar 16, 2017 at 05:53:38PM +0800, Wei Chen wrote: > This patch is based on the implementation of ARM64, it introduces > alternative runtime patching to ARM32. This allows to patch assembly > instruction at runtime to either fix hardware bugs or optimize for > certain hardware features on

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

>>> On 17.03.17 at 14:36, wrote: > On 03/17/2017 03:48 AM, Jan Beulich wrote: > On 16.03.17 at 20:35, wrote: >>> --- a/xen/arch/x86/time.c >>> +++ b/xen/arch/x86/time.c >>> @@ -2051,17 +2051,12 @@ void tsc_set_info(struct domain *d, >>>

Re: [Xen-devel] Wondering about cirris and stdvga

On Fri, Nov 25, 2016 at 07:17:31PM +0100, Dario Faggioli wrote: > On Mon, 2016-11-21 at 10:04 +0100, Dario Faggioli wrote: > > On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote: > > > 2) It'd good to create an upstream Wayland bugreport and > > > investigate > > > more about why cirrus is

Re: [Xen-devel] [PATCH v2] x86/time: Don't use virtual TSC if host and guest frequencies are equal

On 03/17/2017 03:48 AM, Jan Beulich wrote: On 16.03.17 at 20:35, wrote: >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -2051,17 +2051,12 @@ void tsc_set_info(struct domain *d, >> d->arch.vtsc_offset = get_s_time() - elapsed_nsec; >>

[Xen-devel] [PATCH] xen: use libxendevice model to restrict operations

This patch adds a command-line option (-xen-domid-restrict) which will use the new libxendevicemodel API to restrict devicemodel operations to the specified domid. This patch also adds a tracepoint to allow successful enabling of the restriction to be monitored. Signed-off-by: Paul Durrant

Re: [Xen-devel] [PATCH v3 7/9] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

On Thu, 16 Mar 2017 13:01:56 -0700 Stefano Stabellini wrote: > Implement xen_9pfs_init_in/out_iov_from_pdu and > xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the > data on the ring. > > This is safe as we only handle one request per ring at any given

Re: [Xen-devel] [PATCH v3 5/9] xen/9pfs: connect to the frontend

On Thu, 16 Mar 2017 13:01:54 -0700 Stefano Stabellini wrote: > Write the limits of the backend to xenstore. Connect to the frontend. > Upon connection, allocate the rings according to the protocol > specification. > > Initialize a QEMUBH to schedule work upon receiving

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

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

Re: [Xen-devel] [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

On Fri, 2017-03-17 at 01:42 -0600, Jan Beulich wrote: > > > > On 16.03.17 at 22:30, wrote: > > +{ > > +struct domain *d = v->domain; > > + > > +if ( likely(d->cpupool != NULL) ) > > +return d->cpupool->sched; > > + > > +/* v->processor never changes

[Xen-devel] [libvirt test] 106736: trouble: blocked/broken/fail/pass

flight 106736 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106736/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 3 host-install(3)broken REGR. vs. 106707

[Xen-devel] [ovmf test] 106731: regressions - FAIL

flight 106731 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/106731/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963

Re: [Xen-devel] [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP

On Fri, 2017-03-17 at 06:28 +0100, Juergen Gross wrote: > On 16/03/17 22:30, Dario Faggioli wrote: > > [..] > > Fix this by taking care, in VCPU2OP, of the case > > when the vcpu is an idle one. > > > > Signed-off-by: Dario Faggioli > > Reviewed-by: Juergen Gross

Re: [Xen-devel] [Qemu-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1489750157-17401-1-git-send-email-tianyu@intel.com Subject: [Qemu-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base

Re: [Xen-devel] [PATCH 1/4] docs: update dmop.markdown

> -Original Message- > From: Andrew Cooper > Sent: 17 March 2017 11:33 > To: Paul Durrant ; Wei Liu ; > Xen-devel > Cc: Jan Beulich ; Roger Pau Monne > > Subject: Re:

[Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

This patchset is to add Xen vIOMMU device model and handle irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor and the new device module in Qemu works as hypercall wrappers to create and destroy vIOMMU in hypervisor. Xen only supports emulated I440 and so we enable vIOMMU with

[Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

From: Chao Gao As remapping format interrupt has been introduced, the vector in msi remapping format can also be 0, same as a interrupt is binded with a event channel. So we can't just use whether vector is 0 or not to judge a msi is binded to a event channel or not. This

[Xen-devel] [RFC PATCH 2/4] Xen: add a dummy vIOMMU to create/destroy vIOMMU in Xen

From: Chao Gao Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE as parent class. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- hw/xen/Makefile.objs | 1 + hw/xen/xen_viommu.c | 116

[Xen-devel] [RFC PATCH 3/4] 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 use new interfaces to

[Xen-devel] [RFC PATCH 22/23] X86/vvtd: Handle interrupt translation faults

From: Chao Gao Interrupt translation faults are non-recoverable. When fault is 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. In this patch, the process how hardware

[Xen-devel] [RFC PATCH 20/23] Tools/libxc: Add a new interface to bind msi-ir with pirq

From: Chao Gao Introduce a new guest interrupt type and provide a new interface to Qemu to setup/update/unbind the new interrupt type. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- tools/libxc/include/xenctrl.h | 17

[Xen-devel] [RFC PATCH 23/23] 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] [RFC PATCH 21/23] X86/vmsi: Hook guest MSI injection

From: Chao Gao In two situations, hypervisor injects 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 binded to a msi interrupt of guest. The binding relationship

[Xen-devel] [RFC PATCH 19/23] passthrough: move some fields of hvm_gmsi_info to a sub-structure

From: Chao Gao No functional change. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/arch/x86/hvm/vmsi.c | 4 ++-- xen/drivers/passthrough/io.c | 34 +- xen/include/xen/hvm/irq.h

[Xen-devel] [RFC PATCH 17/23] X86/vvtd: Enable Interrupt Remapping through GCMD

From: Chao Gao Software uses 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/arch/x86/hvm/vvtd.c | 26

[Xen-devel] [RFC PATCH 12/23] 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 uses

[Xen-devel] [RFC PATCH 9/23] Tools/libxl: Inform device model to create a guest with a vIOMMU device

From: Chao Gao A new device, xen_viommu, is added to qemu. In xen side, we can inform device model to create a guest with a vIOMMU device through "-device xen_viommu" when a viommu has been configurated in guest configuration file. Some specific parameters are passed through

[Xen-devel] [RFC PATCH 11/23] X86/vvtd: Add MMIO handler for VVTD

From: Chao Gao This patch is to add VVTD MMIO handler to deal with MMIO access. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/arch/x86/hvm/vvtd.c | 135 1 file changed,

[Xen-devel] [RFC PATCH 16/23] 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/arch/x86/hvm/vvtd.c | 18

[Xen-devel] [RFC PATCH 18/23] x86/vpt: Get interrupt vector through a vioapic interface

From: Chao Gao When irq remapping enabled, IRE may not contain the vector of interrupt. So, a new function, vioapic_gsi_vector() is added to translate gsi to vector. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu ---

[Xen-devel] [RFC PATCH 13/23] 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 interrupte request. In this patch, a new function

[Xen-devel] [RFC PATCH 14/23] X86/vvtd: decode interrupt attribute from IRTE

From: Chao Gao Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu --- xen/arch/x86/hvm/vvtd.c | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vvtd.c

[Xen-devel] [RFC PATCH 15/23] X86/vioapic: Hook interrupt delivery of vIOAPIC

From: Chao Gao When irq remapping enabled, IOAPIC Redirection Entry maybe is in remapping format. If that, generate a irq_remapping_request and send it to domain. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu ---

Re: [Xen-devel] [PATCH 3/4] x86/traps: undo the PVHv1 bodge in NMI delivery path

On Fri, Mar 17, 2017 at 11:29:38AM +, Wei Liu wrote: > On Fri, Mar 17, 2017 at 05:26:07AM -0600, Jan Beulich wrote: > > >>> On 17.03.17 at 12:14, wrote: > > > --- a/xen/arch/x86/traps.c > > > +++ b/xen/arch/x86/traps.c > > > @@ -3537,7 +3537,7 @@ static void

[Xen-devel] [RFC PATCH 10/23] x86/hvm: Introduce a emulated VTD for HVM

From: Chao Gao Only add create/destroy function for the emulated VTD in this patch and adapt it to common VIOMMU layer. we will add more sub-feature of this emulated VTD. Signed-off-by: Chao Gao Signed-off-by: Lan Tianyu ---

[Xen-devel] [RFC PATCH 2/23] DMOP: Introduce new DMOP 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/arch/x86/hvm/dm.c | 29 +

[Xen-devel] [RFC PATCH 6/23] 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] [RFC PATCH 8/23] 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 dummy vIOMMU creation. In domain creation process, a new logic is added to build ACPI DMAR table

[Xen-devel] [RFC PATCH 1/23] 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/common/Makefile |

[Xen-devel] [RFC PATCH 7/23] 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] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

From: Chao Gao In previous patch, we introduce a common vIOMMU layer. In our design, we create/destroy vIOMMU through DMOP interface instead of creating it according to a config flag of domain. It makes it is possible to create vIOMMU in device model or in tool stack. The

Re: [Xen-devel] [PATCH 3/4] x86/traps: undo the PVHv1 bodge in NMI delivery path

On Fri, Mar 17, 2017 at 11:31:45AM +, Andrew Cooper wrote: > On 17/03/17 11:29, Wei Liu wrote: > > On Fri, Mar 17, 2017 at 05:26:07AM -0600, Jan Beulich wrote: > > On 17.03.17 at 12:14, wrote: > >>> --- a/xen/arch/x86/traps.c > >>> +++ b/xen/arch/x86/traps.c > >>> @@

[Xen-devel] [RFC PATCH 4/23] 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 | 11 +++ xen/include/asm-arm/viommu.h | 4

[Xen-devel] [RFC PATCH 3/23] 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 | 11 +++ xen/include/asm-arm/viommu.h | 4 xen/include/asm-x86/viommu.h | 15 +++

[Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

This patchset is to introduce vIOMMU framework and add virtual VTD's interrupt remapping support according "Xen virtual IOMMU high level design doc V3"(https://lists.xenproject.org/archives/html/xen-devel/ 2016-11/msg01391.html). - vIOMMU framework New framework provides viommu_ops and help

Re: [Xen-devel] [PATCH 1/4] docs: update dmop.markdown

On 17/03/17 11:30, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of >> Wei Liu >> Sent: 17 March 2017 11:02 >> To: Xen-devel >> Cc: Andrew Cooper ; Wei Liu >>

Re: [Xen-devel] [PATCH 3/4] x86/traps: undo the PVHv1 bodge in NMI delivery path

On 17/03/17 11:29, Wei Liu wrote: > On Fri, Mar 17, 2017 at 05:26:07AM -0600, Jan Beulich wrote: > On 17.03.17 at 12:14, wrote: >>> --- a/xen/arch/x86/traps.c >>> +++ b/xen/arch/x86/traps.c >>> @@ -3537,7 +3537,7 @@ static void nmi_hwdom_report(unsigned int reason_idx)

Re: [Xen-devel] [PATCH 1/4] docs: update dmop.markdown

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Wei Liu > Sent: 17 March 2017 11:02 > To: Xen-devel > Cc: Andrew Cooper ; Wei Liu > ; Jan Beulich

Re: [Xen-devel] [PATCH 3/4] x86/traps: undo the PVHv1 bodge in NMI delivery path

On Fri, Mar 17, 2017 at 05:26:07AM -0600, Jan Beulich wrote: > >>> On 17.03.17 at 12:14, wrote: > > --- a/xen/arch/x86/traps.c > > +++ b/xen/arch/x86/traps.c > > @@ -3537,7 +3537,7 @@ static void nmi_hwdom_report(unsigned int reason_idx) > > { > > struct domain *d =

Re: [Xen-devel] [PATCH 3/4] x86/traps: undo the PVHv1 bodge in NMI delivery path

>>> On 17.03.17 at 12:14, wrote: > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -3537,7 +3537,7 @@ static void nmi_hwdom_report(unsigned int reason_idx) > { > struct domain *d = hardware_domain; > > -if ( !d || !d->vcpu || !d->vcpu[0] ||

Re: [Xen-devel] [RFC PATCH 1/9] xen/device-tree: Add dt_count_phandle_with_args helper

On Thu, Mar 16, 2017 at 5:39 PM, Julien Grall wrote: > Hi Oleksandr, Hi Julien > > On 03/15/2017 08:05 PM, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> Port Linux helper of_count_phandle_with_args for counting >> number

Re: [Xen-devel] [RFC PATCH 0/9] "Non-shared" IOMMU support on ARM

On Thu, Mar 16, 2017 at 5:31 PM, Julien Grall wrote: > On 03/15/2017 08:05 PM, Oleksandr Tyshchenko wrote: >> >> Hi, all. > > > Hi Oleksandr, Hi Julien > > Thank you for looking at the support of "non-shared" page table IOMMU > support. > >> >> The purpose of this patch

  1   2   >