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

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

[Xen-devel] [PATCH] xen/scsifront: use offset_in_page() macro

Use offset_in_page() macro instead of open-coding. Signed-off-by: Geliang Tang --- drivers/scsi/xen-scsifront.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c index 9aa1fe1..a6a8b60 100644

[Xen-devel] [qemu-mainline baseline-only test] 71216: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71216 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71216/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 6 xen-boot

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

flight 107589 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107589/ 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 12

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Fri, 21 Apr 2017, Julien Grall wrote: > Hi Volodymyr, > > On 21/04/17 18:04, Volodymyr Babchuk wrote: > > On 21 April 2017 at 19:47, Julien Grall wrote: > > > On 21/04/17 17:16, Volodymyr Babchuk wrote: > > > > On 21 April 2017 at 18:57, Julien Grall

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Fri, 21 Apr 2017, Stefano Stabellini wrote: > Hello Andrii, > > could you please use plain text (not HTML) in your emails? > > On Fri, 21 Apr 2017, Andrii Anisov wrote: > > > > Hello, > > > > On 20.04.17 23:20, Volodymyr Babchuk wrote: > > > > Hi Stefano, > > > > On 12 April 2017 at

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hello Andrii, could you please use plain text (not HTML) in your emails? On Fri, 21 Apr 2017, Andrii Anisov wrote: > > Hello, > > On 20.04.17 23:20, Volodymyr Babchuk wrote: > > Hi Stefano, > > On 12 April 2017 at 22:17, Stefano Stabellini wrote: > > On Wed, 12 Apr

Re: [Xen-devel] [PATCH v2 for-4.9] xen/arm: Don't unflatten DT when booting with ACPI

On Fri, 21 Apr 2017, Punit Agrawal wrote: > Unflattening the device tree when booting with "acpi=force" leads to the > following stack trace on AMD Seattle platform - > > (XEN) Xen call trace: > (XEN)[<00204bfc>] dt_irq_translate+0x48/0x58 (PC) > (XEN)[<00204f5c>]

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

flight 107588 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107588/ 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 12

[Xen-devel] [PULL 21/21] move xen-mapcache.c to hw/i386/xen/

From: Anthony Xu move xen-mapcache.c to hw/i386/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target| 3 - default-configs/i386-softmmu.mak | 1 -

[Xen-devel] [libvirt test] 107577: tolerable all pass - PUSHED

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

[Xen-devel] [PULL 01/21] xen: make use of xen_xc implicit in xen_common.h inlines

From: Paul Durrant Doing this will make the transition to using the new libxendevicemodel interface less intrusive on the callers of these functions, since using the new library will require a change of handle. NOTE: The patch also moves the 'externs' for xen_xc and

[Xen-devel] [PULL 19/21] move xen-common.c to hw/xen/

From: Anthony Xu move xen-common.c to hw/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target | 2 - hw/xen/Makefile.objs | 2 +- hw/xen/xen-common.c | 169

[Xen-devel] [PULL 04/21] configure: detect presence of libxendevicemodel

From: Paul Durrant This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION to a new value of 490 if libxendevicemodel is present in the build environment. Signed-off-by: Paul Durrant Signed-off-by: Stefano Stabellini

[Xen-devel] [PULL 07/21] xen: use libxendevice model to restrict operations

From: Paul Durrant This patch adds a command-line option (-xen-domid-restrict) which will use the new libxendevicemodel API to restrict devicemodel [1] operations to the specified domid. (Such operations are not applicable to the xenpv machine type). This patch also

[Xen-devel] [PULL 17/21] xen/9pfs: build and register Xen 9pfs backend

Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/Makefile.objs| 1 + hw/xen/xen_backend.c

[Xen-devel] [PULL 20/21] move xen-hvm.c to hw/i386/xen/

From: Anthony Xu move xen-hvm.c to hw/i386/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target |3 +- hw/i386/xen/Makefile.objs |2 +- hw/i386/xen/trace-events | 11 +

[Xen-devel] [PULL 13/21] xen/9pfs: connect to the frontend

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 an event channel notification from the frontend. Signed-off-by: Stefano Stabellini

[Xen-devel] [PULL 16/21] xen/9pfs: send responses back to the frontend

Once a request is completed, xen_9pfs_push_and_notify gets called. In xen_9pfs_push_and_notify, update the indexes (data has already been copied to the sg by the common code) and send a notification to the frontend. Schedule the bottom-half to check if we already have any other requests pending.

[Xen-devel] [PULL 18/21] add xen-9p-backend to MAINTAINERS under Xen

Signed-off-by: Stefano Stabellini Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: gr...@kaod.org CC: anthony.per...@citrix.com --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS

[Xen-devel] [PULL 12/21] xen/9pfs: introduce Xen 9pfs backend

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC:

[Xen-devel] [PULL 03/21] xen: create wrappers for all other uses of xc_hvm_XXX() functions

From: Paul Durrant This patch creates inline wrapper functions in xen_common.h for all open coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use of xen_xc can be made implicit. This again is in preparation for the move to using libxendevicemodel.

[Xen-devel] [PULL 09/21] configure: use pkg-config for obtaining xen version

From: Juergen Gross 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 return the version fall back to the test program scheme. If configure is being called with dedicated flags for the

[Xen-devel] [PULL 11/21] 9p: introduce a type for the 9p header

Use the new type in virtio-9p-device. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz Reviewed-by: Philippe Mathieu-Daudé CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC:

[Xen-devel] [PULL 02/21] xen: rename xen_modified_memory() to xen_hvm_modified_memory()

From: Paul Durrant This patch is a purely cosmetic change that avoids a name collision in a subsequent patch. Signed-off-by: Paul Durrant Reviewed-by: Anthony Perard Reviewed-by: Stefano Stabellini

[Xen-devel] [PULL 15/21] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

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 time. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC:

[Xen-devel] [PULL 08/21] xen: additionally restrict xenforeignmemory operations

From: Paul Durrant Commit f0f272baf3a7 "xen: use libxendevice model to restrict operations" added a command-line option (-xen-domid-restrict) to limit operations using the libxendevicemodel API to a specified domid. The commit also noted that the restriction would be

[Xen-devel] [PULL 14/21] xen/9pfs: receive requests from the frontend

Upon receiving an event channel notification from the frontend, schedule the bottom half. From the bottom half, read one request from the ring, create a pdu and call pdu_submit to handle it. For now, only handle one request per ring at a time. Signed-off-by: Stefano Stabellini

[Xen-devel] [PULL 05/21] xen: use libxendevicemodel when available

From: Paul Durrant This patch modifies the wrapper functions in xen_common.h to use the new xendevicemodel interface if it is available along with compatibility code to use the old libxenctrl interface if it is not. Signed-off-by: Paul Durrant

[Xen-devel] [PULL 10/21] xen: import ring.h from xen

Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz

[Xen-devel] [PULL 06/21] xen: use 5 digit xen versions

From: Juergen Gross Today qemu is using e.g. the value 480 for Xen version 4.8.0. As some Xen version tests are using ">" relations this scheme will lead to problems when Xen version 4.10.0 is being reached. Instead of the 3 digit schem use a 5 digit scheme (e.g. 40800 for

[Xen-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059: Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170421-tag for you to fetch changes up

[Xen-devel] [distros-debian-jessie test] 71214: tolerable trouble: blocked/broken/pass

flight 71214 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71214/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a build-arm64-pvops

Re: [Xen-devel] [RFC PATCH 4/9] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

On Fri, Apr 21, 2017 at 7:27 PM, Julien Grall wrote: > > > On 21/04/17 15:18, Oleksandr Tyshchenko wrote: >> >> On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall >> wrote: >>> >>> Hi Oleksandr, >> >> Hi, Julien > > > Hi Oleksandr, Hi, Julien > > >>> >>>

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 20:38, Julien Grall wrote: > Hi Volodymyr, > > On 21/04/17 18:04, Volodymyr Babchuk wrote: >> >> On 21 April 2017 at 19:47, Julien Grall wrote: >>> >>> On 21/04/17 17:16, Volodymyr Babchuk wrote: On 21 April

Re: [Xen-devel] linux 4.9 fails with nested Xen

Boris Ostrovsky writes ("Re: linux 4.9 fails with nested Xen"): > This is the same failure that was discussed earlier --- lack of commit > da72ff5bfcb02 (partially revert "xen: Remove event channel notification > through Xen PCI platform device") in 4.9 tree. > > This actual offending commit

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

On Fri, 21 Apr 2017, Lars Kurth wrote: > On 21/04/2017 12:01, "Julien Grall" wrote: > > >Hi, > > > >On 21/04/17 01:01, osstest service owner wrote: > >> flight 107560 xen-unstable real [real] > >> http://logs.test-lab.xenproject.org/osstest/logs/107560/ > >> > >> Failures

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

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

[Xen-devel] [xen-unstable baseline-only test] 71213: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71213 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71213/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Volodymyr, On 21/04/17 18:04, Volodymyr Babchuk wrote: On 21 April 2017 at 19:47, Julien Grall wrote: On 21/04/17 17:16, Volodymyr Babchuk wrote: On 21 April 2017 at 18:57, Julien Grall wrote: Hello Volodymyr, On 20/04/17 21:20, Volodymyr

Re: [Xen-devel] linux 4.9 fails with nested Xen

On 04/21/2017 12:06 PM, Boris Ostrovsky wrote: > On 04/21/2017 09:21 AM, Ian Jackson wrote: >> osstest service owner writes ("[linux-4.9 test] 107573: regressions - FAIL"): >>> flight 107573 linux-4.9 real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/107573/ >> ... >>>

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Julien, On 21 April 2017 at 19:47, Julien Grall wrote: > On 21/04/17 17:16, Volodymyr Babchuk wrote: >> >> Hi Julien, > > > Hi Volodymyr, > > >> On 21 April 2017 at 18:57, Julien Grall wrote: >>> >>> Hello Volodymyr, >>> >>> On 20/04/17 21:20,

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On 21/04/17 17:16, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 21 April 2017 at 18:57, Julien Grall wrote: Hello Volodymyr, On 20/04/17 21:20, Volodymyr Babchuk wrote: On 12 April 2017 at 22:17, Stefano Stabellini wrote: On Wed,

Re: [Xen-devel] [RFC PATCH 4/9] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

On 21/04/17 15:18, Oleksandr Tyshchenko wrote: On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall wrote: Hi Oleksandr, Hi, Julien Hi Oleksandr, On 15/03/17 20:05, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Update IOMMU

Re: [Xen-devel] [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 20 April 2017 16:18 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Ian Jackson ; Wei Liu >

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Julien, I don't think we should think in term of type of application supported. We should aim to have a generic interface we can maintain based on the needs. I was just pointing out the use-case missed in the discussion of the interface intended to be generic. It introduces new requirements

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 18:57, Julien Grall wrote: > Hello Volodymyr, > > On 20/04/17 21:20, Volodymyr Babchuk wrote: >> >> On 12 April 2017 at 22:17, Stefano Stabellini >> wrote: >>> >>> On Wed, 12 Apr 2017, Dario Faggioli wrote:

Re: [Xen-devel] [PATCH] docs: fix iommu_inclusive_mapping documentation

On Fri, Apr 21, 2017 at 10:01:36AM -0600, Jan Beulich wrote: > >>> On 21.04.17 at 16:36, wrote: > > --- a/docs/misc/xen-command-line.markdown > > +++ b/docs/misc/xen-command-line.markdown > > @@ -1083,7 +1083,7 @@ wait descriptor timed out', try increasing this value. > >

Re: [Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

On 21/04/17 16:45, Jan Beulich wrote: On 21.04.17 at 16:05, wrote: >> +#define COPY_FROM_GUEST_BUF(dst, args, buf_idx) \ >> +_raw_copy_from_guest_buf(, args, buf_idx, sizeof(dst)) >> + >> +#define COPY_TO_GUEST_BUF(args, buf_idx, src) \ >> +

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 18:49, Julien Grall wrote: > > > On 21/04/17 15:42, Andrii Anisov wrote: >> >> Hello, > > > Hi, > >> On 20.04.17 23:20, Volodymyr Babchuk wrote: >>> >>> Hi Stefano, >>> >>> On 12 April 2017 at 22:17, Stefano Stabellini

Re: [Xen-devel] [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 20 April 2017 16:18 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Ian Jackson ; Wei Liu >

Re: [Xen-devel] linux 4.9 fails with nested Xen

On 04/21/2017 09:21 AM, Ian Jackson wrote: > osstest service owner writes ("[linux-4.9 test] 107573: regressions - FAIL"): >> flight 107573 linux-4.9 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/107573/ > ... >> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail

Re: [Xen-devel] [PATCH] x86/mmcfg: set pci_mmcfg_config_num to 0 on error path

>>> On 21.04.17 at 15:43, wrote: > One error path of acpi_parse_mcfg doesn't set pci_mmcfg_config_num to zero, > fix > this. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich > --- a/xen/arch/x86/x86_64/acpi_mmcfg.c >

Re: [Xen-devel] [PATCH] docs: fix iommu_inclusive_mapping documentation

>>> On 21.04.17 at 16:36, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1083,7 +1083,7 @@ wait descriptor timed out', try increasing this value. > ### iommu\_inclusive\_mapping (VT-d) > > `= ` > > -> Default: `false`

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hello Volodymyr, On 20/04/17 21:20, Volodymyr Babchuk wrote: On 12 April 2017 at 22:17, Stefano Stabellini wrote: On Wed, 12 Apr 2017, Dario Faggioli wrote: On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Stefano Stabellini wrote: We

Re: [Xen-devel] x86: mapping from Dom0 to DomU

>>> On 21.04.17 at 15:04, wrote: > Hi, all! > > I am working on a zero-copy scenario for x86 > and for that I am mapping pages from Dom0 to DomU > (yes, I know there are at least security concerns). > > Everything is just fine, e.g. I can map grefs from Dom0 in DomU > with

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On 21/04/17 15:42, Andrii Anisov wrote: Hello, Hi, On 20.04.17 23:20, Volodymyr Babchuk wrote: Hi Stefano, On 12 April 2017 at 22:17, Stefano Stabellini wrote: On Wed, 12 Apr 2017, Dario Faggioli wrote: On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini

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

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

Re: [Xen-devel] [PATCH v8 for-4.9 4/5] hvm/dmop: Implement copy_{to, from}_guest_buf_offset() helpers

>>> On 21.04.17 at 16:05, wrote: > From: Andrew Cooper > > copy_{to,from}_guest_buf() are now implemented using an offset of 0. > > Signed-off-by: Andrew Cooper > Signed-off-by: Jennifer Herbert

Re: [Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

>>> On 21.04.17 at 16:05, wrote: > +#define COPY_FROM_GUEST_BUF(dst, args, buf_idx) \ > +_raw_copy_from_guest_buf(, args, buf_idx, sizeof(dst)) > + > +#define COPY_TO_GUEST_BUF(args, buf_idx, src) \ > +_raw_copy_to_guest_buf(args, buf_idx, , sizeof(src)) Why

Re: [Xen-devel] [PATCH for-next 5/7] x86_64: move PV specific code under pv/x86_64

>>> On 21.04.17 at 14:52, wrote: > On Fri, Apr 21, 2017 at 03:33:11AM -0600, Jan Beulich wrote: >> >>> On 06.04.17 at 19:14, wrote: >> > -void subarch_percpu_traps_init(void) >> > -{ >> > -unsigned long stack_bottom = get_stack_bottom(); >> > -

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

flight 107575 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107575/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs.

[Xen-devel] [PATCH v2] xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()

e820 map is updated with information from the zeropage (i.e. pvh_bootparams) by default_machine_specific_memory_setup(). With the way things are done now, we end up with a duplicated e820 map. Signed-off-by: Boris Ostrovsky --- v2: * Drop sanitize_e820_map() since it

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 04/21/2017 10:45 AM, Andrew Cooper wrote: > On 21/04/17 15:38, Juergen Gross wrote: >> On 21/04/17 16:24, Boris Ostrovsky wrote: +static bool __init xen_check_xsave(void) { - unsigned int ax, bx, cx, dx; - unsigned int xsave_mask; + unsigned int err, eax, edx;

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 15:38, Juergen Gross wrote: > On 21/04/17 16:24, Boris Ostrovsky wrote: >>> +static bool __init xen_check_xsave(void) >>> { >>> - unsigned int ax, bx, cx, dx; >>> - unsigned int xsave_mask; >>> + unsigned int err, eax, edx; >>> >>> - ax = 1; >>> - cx = 0; >>> - cpuid(1,

Re: [Xen-devel] [PATCH v8 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

Hi Julien, This is extending an existing feature. Once 4.9 is released, the existing feature will be frozen, and the only way to later get the extra functionality would be to created a completely new dm_op, which does something very similar to an existing one. Although not the end of the

Re: [Xen-devel] [PATCH v8 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

On 21/04/17 15:17, Julien Grall wrote: > Hi Jennifer, > > I don't see any cover letter for this series, so I will answer here. > > Looking at the code, it looks like a new feature rather than a bug > fix. Am I right? > > Could you explain what would be the benefits and risks to get this > code in

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

On Wed, Apr 19, 2017 at 9:26 PM, Julien Grall wrote: > Hi Oleksandr, Hi, Julien > > Please CC the appropriate maintainers for all the components you modify. Sorry, sure. > > > On 15/03/17 20:05, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hello, On 20.04.17 23:20, Volodymyr Babchuk wrote: Hi Stefano, On 12 April 2017 at 22:17, Stefano Stabellini wrote: On Wed, 12 Apr 2017, Dario Faggioli wrote: On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Stefano Stabellini wrote:

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 16:24, Boris Ostrovsky wrote: > >> +static bool __init xen_check_xsave(void) >> { >> -unsigned int ax, bx, cx, dx; >> -unsigned int xsave_mask; >> +unsigned int err, eax, edx; >> >> -ax = 1; >> -cx = 0; >> -cpuid(1, , , , ); >> +/* Test OSXSAVE

[Xen-devel] [PATCH] docs: fix iommu_inclusive_mapping documentation

iommu_inclusive_mapping is enabled by default (and has been for a long time). Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich

Re: [Xen-devel] [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

> +static bool __init xen_check_xsave(void) > { > - unsigned int ax, bx, cx, dx; > - unsigned int xsave_mask; > + unsigned int err, eax, edx; > > - ax = 1; > - cx = 0; > - cpuid(1, , , , ); > + /* Test OSXSAVE capability via xgetbv instruction. */ > + asm

Re: [Xen-devel] [RFC PATCH 4/9] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

On Wed, Apr 19, 2017 at 8:46 PM, Julien Grall wrote: > Hi Oleksandr, Hi, Julien > > On 15/03/17 20:05, Oleksandr Tyshchenko wrote: >> >> From: Oleksandr Tyshchenko >> >> Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.

Re: [Xen-devel] [PATCH v8 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

Hi Jennifer, I don't see any cover letter for this series, so I will answer here. Looking at the code, it looks like a new feature rather than a bug fix. Am I right? Could you explain what would be the benefits and risks to get this code in the release? I also like to hear the opinion of

[Xen-devel] [PATCH v3 20/29] x86: xen-pvh, annotate data appropriatelly

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros: 8 OBJECT LOCAL DEFAULT6 gdt 000832 OBJECT LOCAL DEFAULT6 gdt_start 0028 0 OBJECT LOCAL DEFAULT6 gdt_end 0028 256 OBJECT LOCAL DEFAULT6 early_stack 0128 0 OBJECT LOCAL DEFAULT6

[Xen-devel] [PATCH v3 15/29] x86: assembly, annotate aliases

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy.

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

On Fri, Apr 21, 2017 at 10:00:16PM +0800, Tian, Kevin wrote: >btw I'm thinking whether adding lock in vmx_intr_assist is >necessary... Can you think whether below option may >work? > >Do lock protection within pt_update_irq. Make sure vector >not changed between setting vIRR and finding

Re: [Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

> -Original Message- > From: jennifer.herb...@citrix.com [mailto:jennifer.herb...@citrix.com] > Sent: 21 April 2017 15:06 > To: Xen-devel > Cc: Andrew Cooper ; Jennifer Herbert > ; Paul Durrant

[Xen-devel] [PATCH v3 26/29] x86_64: assembly, change all ENTRY to SYM_FUNC_START

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START (and their ENDPROC's by SYM_FUNC_END.) And make sure ENTRY/ENDPROC is not defined on X86_64. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc:

[Xen-devel] [PATCH v3 27/29] x86_32: assembly, change all ENTRY to SYM_FUNC_START

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START (and their ENDPROC's by SYM_FUNC_END.) Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar

[Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

Somewhere END was used to end a function. It is not intended to be used for functions, because it does not mark the actual symbols as functions. Use ENDPROC in such cases which does the right job. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar

[Xen-devel] [PATCH v3 25/29] x86: assembly, make some functions local

There is couple of assembly functions, which are invoked only locally in a file they are defined. In C, we mark them "static". Annotate them here using SYM_FUNC_START_LOCAL (and switch their ENDPROC to SYM_FUNC_END too). Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin"

[Xen-devel] [PATCH v3 05/29] x86: assembly, add ENDPROC to functions

Some functions are annotated as ENTRY or GLOBAL, but their ends are not annotated at all. This means: * the annotations are not paired and we cannot deal with such functions e.g. in objtool * the symbols are not marked as functions in the object file * there are no sizes of the functions in the

[Xen-devel] [PATCH v3 08/29] linkage: new macros for assembler symbols

Introduce new C macros for annotations of functions and data in assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros

Re: [Xen-devel] [PATCH v8 for-4.9 2/5] hvm/dmop: Make copy_buf_{from, to}_guest for a buffer not big enough an error.

> -Original Message- > From: jennifer.herb...@citrix.com [mailto:jennifer.herb...@citrix.com] > Sent: 21 April 2017 15:06 > To: Xen-devel > Cc: Jennifer Herbert ; Jennifer Herbert > ; Paul Durrant

[Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

From: Andrew Cooper This also allows the usual cases to be simplified, by omitting an unnecessary buf parameters, and because the macros can appropriately size the object. Signed-off-by: Andrew Cooper Signed-off-by: Jennifer Herbert

[Xen-devel] [PATCH v8 for-4.9 5/5] dmop: Add xendevicemodel_modified_memory_bulk()

From: Jennifer Herbert This new lib devicemodel call allows multiple extents of pages to be marked as modified in a single call. This is something needed for a usecase I'm working on. The xen side of the modified_memory call has been modified to accept an array of

[Xen-devel] [PATCH v8 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

From: Jennifer Herbert No functional change. Signed-off-by: Jennifer Herbert Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant --

[Xen-devel] [PATCH v8 for-4.9 4/5] hvm/dmop: Implement copy_{to, from}_guest_buf_offset() helpers

From: Andrew Cooper copy_{to,from}_guest_buf() are now implemented using an offset of 0. Signed-off-by: Andrew Cooper Signed-off-by: Jennifer Herbert Reviewed-by: Paul Durrant

[Xen-devel] [PATCH v8 for-4.9 2/5] hvm/dmop: Make copy_buf_{from, to}_guest for a buffer not big enough an error.

From: Jennifer Herbert This makes copying to or from a buf that isn't big enough an error. If the buffer isnt big enough, trying to carry on regardless can only cause trouble later on. Signed-off-by: Jennifer Herbert -- CC: Paul Durrant

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

> From: Gao, Chao > Sent: Friday, April 21, 2017 12:23 PM > > >> @@ -487,13 +494,14 @@ int vpic_ack_pending_irq(struct vcpu *v) > >> struct hvm_hw_vpic *vpic = >domain->arch.hvm_domain.vpic[0]; > >> > >> ASSERT(has_vpic(v->domain)); > >> +ASSERT(vpic_is_locked(vpic)); > >> > >>

[Xen-devel] [PATCH] x86/mmcfg: set pci_mmcfg_config_num to 0 on error path

One error path of acpi_parse_mcfg doesn't set pci_mmcfg_config_num to zero, fix this. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/x86_64/acpi_mmcfg.c | 1 + 1 file changed, 1

Re: [Xen-devel] [PATCH v7 for-4.9 2/5] hvm/dmop: Make copy_buf_{from, to}_guest for a buffer not big enough an error.

> -Original Message- > From: jennifer.herb...@citrix.com [mailto:jennifer.herb...@citrix.com] > Sent: 21 April 2017 14:16 > To: Xen-devel > Cc: Jennifer Herbert ; Jennifer Herbert > ; Paul Durrant

[Xen-devel] linux 4.9 fails with nested Xen

osstest service owner writes ("[linux-4.9 test] 107573: regressions - FAIL"): > flight 107573 linux-4.9 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/107573/ ... > test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass > test-amd64-amd64-qemuu-nested-amd 13

Re: [Xen-devel] [PATCH v7 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

> -Original Message- > From: jennifer.herb...@citrix.com [mailto:jennifer.herb...@citrix.com] > Sent: 21 April 2017 14:16 > To: Xen-devel > Cc: Jennifer Herbert ; Andrew Cooper > ; Paul Durrant

[Xen-devel] [PATCH v7 for-4.9 2/5] hvm/dmop: Make copy_buf_{from, to}_guest for a buffer not big enough an error.

From: Jennifer Herbert This makes copying to or from a buf that isn't big enough an error. If the buffer isnt big enough, trying to carry on regardless can only cause trouble later on. Signed-off-by: Jennifer Herbert -- CC: Paul Durrant

[Xen-devel] [PATCH v7 for-4.9 4/5] hvm/dmop: Implement copy_{to, from}_guest_buf_offset() helpers

From: Andrew Cooper copy_{to,from}_guest_buf() are now implemented using an offset of 0. Signed-off-by: Andrew Cooper Signed-off-by: Jennifer Herbert Reviewed-by: Paul Durrant

[Xen-devel] [PATCH v7 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

From: Andrew Cooper This also allows the usual cases to be simplified, by omitting an unnecessary buf parameters, and because the macros can appropriately size the object. Signed-off-by: Andrew Cooper Signed-off-by: Jennifer Herbert

[Xen-devel] [PATCH v7 for-4.9 1/5] hvm/dmop: Box dmop_args rather than passing multiple parameters around

From: Jennifer Herbert No functional change. Signed-off-by: Jennifer Herbert Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant --

[Xen-devel] [PATCH v7 for-4.9 5/5] dmop: Add xendevicemodel_modified_memory_bulk()

From: Jennifer Herbert This new lib devicemodel call allows multiple extents of pages to be marked as modified in a single call. This is something needed for a usecase I'm working on. The xen side of the modified_memory call has been modified to accept an array of

  1   2   >