Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 19:28, wrote: > On 20/11/17 17:14, Jan Beulich wrote: > On 20.11.17 at 16:24, wrote: >>> On 20/11/17 15:20, Jan Beulich wrote: >>> On 20.11.17 at 15:14, wrote: > On 20/11/17 14:56, Boris Ostrovsky wrote: >> On 11/20/2017 06:50 AM, Jan Beulich wrote: >>

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 17:59, wrote: > On 11/20/2017 11:43 AM, Jan Beulich wrote: > On 20.11.17 at 17:28, wrote: >>> On 11/20/2017 11:26 AM, Jan Beulich wrote: >>> On 20.11.17 at 17:14, wrote: > What could cause grub2 to fail to find space for the pointer in the > first page? Will we

[Xen-devel] [Draft Design v3] ACPI/IORT Support in Xen.

 ACPI/IORT Support in Xen.  --   Draft 3  Revision History:  Changes since v2:  - Modified as per comments from Julien /Sameer/Andre  Changes since v1:  - Modified IORT Parsing data structures.  - Added RID-StreamID and RID-DeviceID map as per Andre's suggestion.  -

[Xen-devel] [linux-next test] 116368: regressions - trouble: broken/fail/pass

flight 116368 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/116368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair broken test-amd64-i386-libvirt-qcow2

[Xen-devel] [qemu-mainline test] 116369: trouble: broken/fail/pass

flight 116369 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116369/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-amd broken test-armhf-armhf-x

[Xen-devel] [xen-4.7-testing baseline-only test] 72467: regressions - FAIL

This run is configured for baseline tests only. flight 72467 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72467/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 21

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-debianhvm-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-tr

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

flight 116366 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116366/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm broken test-armhf-armhf-xl-credit2 17 guest-sta

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

flight 116370 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/116370/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 167052779c0546e99aadd26ebd848e10f91fb557 baseline version: xtf 4d18dd4a163b7879c262ac

[Xen-devel] [xen-4.5-testing test] 116356: regressions - FAIL

flight 116356 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116356/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115226 Tests which are

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

flight 116362 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116362/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116328 test-armhf-armhf-libvirt-xsm 14 saveresto

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 17:14, Boris Ostrovsky wrote: > On 11/20/2017 10:27 AM, Juergen Gross wrote: >> On 20/11/17 15:25, Boris Ostrovsky wrote: >>> On 11/20/2017 09:14 AM, Juergen Gross wrote: On 20/11/17 14:56, Boris Ostrovsky wrote: > On 11/20/2017 06:50 AM, Jan Beulich wrote: > On 20.11.1

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 17:14, Jan Beulich wrote: On 20.11.17 at 16:24, wrote: >> On 20/11/17 15:20, Jan Beulich wrote: >> On 20.11.17 at 15:14, wrote: On 20/11/17 14:56, Boris Ostrovsky wrote: > On 11/20/2017 06:50 AM, Jan Beulich wrote: > On 20.11.17 at 12:20, wrote: >>> Whic

Re: [Xen-devel] Next Xen Arm Community call - Wednesday 22nd November

Answering to myself. On 16 November 2017 at 11:54, Julien Grall wrote: > Hi all, > > Apologies I was meant to organize the call earlier. > > I would suggest to have the next community call on Wednesday 22nd November > 5pm GMT. Does it sound good? > > Do you have any specific topic you would like

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On 20/11/2017 08:05, Quan Xu wrote: [ ... ] But the irq_timings stuff is heading into the same direction, with a more complex prediction logic which should tell you pretty good how long that idle period is going to be and in case of an interrupt heavy workload this >

Re: [Xen-devel] [PATCH 01/16] Introduce skeleton SUPPORT.md

>>> On 13.11.17 at 16:41, wrote: > Add a machine-readable file to describe what features are in what > state of being 'supported', as well as information about how long this > release will be supported, and so on. > > The document should be formatted using "semantic newlines" [1], to make > chang

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 11:43 AM, Jan Beulich wrote: On 20.11.17 at 17:28, wrote: >> On 11/20/2017 11:26 AM, Jan Beulich wrote: >> On 20.11.17 at 17:14, wrote: What could cause grub2 to fail to find space for the pointer in the first page? Will we ever have anything in EBDA (which is one

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 17:28, wrote: > On 11/20/2017 11:26 AM, Jan Beulich wrote: > On 20.11.17 at 17:14, wrote: >>> What could cause grub2 to fail to find space for the pointer in the >>> first page? Will we ever have anything in EBDA (which is one of the >>> possible RSDP locations)? >> Well, t

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 11:26 AM, Jan Beulich wrote: On 20.11.17 at 17:14, wrote: >> What could cause grub2 to fail to find space for the pointer in the >> first page? Will we ever have anything in EBDA (which is one of the >> possible RSDP locations)? > Well, the EBDA (see the B in its name) is again

[Xen-devel] [xen-4.6-testing test] 116350: regressions - trouble: blocked/broken/fail/pass

flight 116350 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116350/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-armhf-libvirt 5 host-b

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 17:14, wrote: > What could cause grub2 to fail to find space for the pointer in the > first page? Will we ever have anything in EBDA (which is one of the > possible RSDP locations)? Well, the EBDA (see the B in its name) is again something that's meaningless without there being

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 10:27 AM, Juergen Gross wrote: > On 20/11/17 15:25, Boris Ostrovsky wrote: >> On 11/20/2017 09:14 AM, Juergen Gross wrote: >>> On 20/11/17 14:56, Boris Ostrovsky wrote: On 11/20/2017 06:50 AM, Jan Beulich wrote: On 20.11.17 at 12:20, wrote: >> Which restriction? I'm

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 16:24, wrote: > On 20/11/17 15:20, Jan Beulich wrote: > On 20.11.17 at 15:14, wrote: >>> On 20/11/17 14:56, Boris Ostrovsky wrote: On 11/20/2017 06:50 AM, Jan Beulich wrote: On 20.11.17 at 12:20, wrote: >> Which restriction? I'm loading the RSDP table to

Re: [Xen-devel] [xen-4.6-testing test] 116250: regressions - FAIL

osstest service owner writes ("[xen-4.6-testing test] 116250: regressions - FAIL"): > flight 116250 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/116250/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be ru

Re: [Xen-devel] [xen-4.5-testing test] 116245: regressions - FAIL

osstest service owner writes ("[xen-4.5-testing test] 116245: regressions - FAIL"): > flight 116245 xen-4.5-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/116245/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be ru

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 15:25, Boris Ostrovsky wrote: > On 11/20/2017 09:14 AM, Juergen Gross wrote: >> On 20/11/17 14:56, Boris Ostrovsky wrote: >>> On 11/20/2017 06:50 AM, Jan Beulich wrote: >>> On 20.11.17 at 12:20, wrote: > Which restriction? I'm loading the RSDP table to its architectural > c

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 15:20, Jan Beulich wrote: On 20.11.17 at 15:14, wrote: >> On 20/11/17 14:56, Boris Ostrovsky wrote: >>> On 11/20/2017 06:50 AM, Jan Beulich wrote: >>> On 20.11.17 at 12:20, wrote: > Which restriction? I'm loading the RSDP table to its architectural > correct addres if

Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Hi, On 20/11/17 15:19, Robin Murphy wrote: On 20/11/17 14:25, Julien Grall wrote: [...] +    else {    cpu_relax(); Hmmm I now see why you added cpu_relax() at the top. Well, on Xen cpu_relax is just a barrier. On Linux it is used to yield. And that bit is worrying me. Th

Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 20/11/17 14:25, Julien Grall wrote: [...] +    else {    cpu_relax(); Hmmm I now see why you added cpu_relax() at the top. Well, on Xen cpu_relax is just a barrier. On Linux it is used to yield. And that bit is worrying me. The Linux code will allow context switching to

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 09:36 AM, Andrew Cooper wrote: > On 20/11/17 14:25, Boris Ostrovsky wrote: >> On 11/20/2017 09:14 AM, Juergen Gross wrote: >>> On 20/11/17 14:56, Boris Ostrovsky wrote: On 11/20/2017 06:50 AM, Jan Beulich wrote: On 20.11.17 at 12:20, wrote: >> Which restriction? I'm

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 14:25, Boris Ostrovsky wrote: > On 11/20/2017 09:14 AM, Juergen Gross wrote: >> On 20/11/17 14:56, Boris Ostrovsky wrote: >>> On 11/20/2017 06:50 AM, Jan Beulich wrote: >>> On 20.11.17 at 12:20, wrote: > Which restriction? I'm loading the RSDP table to its architectural > c

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream

>>> On 20.11.17 at 15:10, wrote: > On 17/11/17 12:10, Jan Beulich wrote: > On 16.11.17 at 20:15, wrote: >>> Doing so amounts to silent state corruption, and must be avoided. >> I think a little more explanation is needed on why the current code >> is insufficient. Note specifically this >> >>

[Xen-devel] [xen-4.7-testing test] 116348: tolerable FAIL - PUSHED

flight 116348 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116348/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail in 116321 pass in 116348 test-amd64-amd64-xl-qemuu

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 09:14 AM, Juergen Gross wrote: > On 20/11/17 14:56, Boris Ostrovsky wrote: >> On 11/20/2017 06:50 AM, Jan Beulich wrote: >> On 20.11.17 at 12:20, wrote: Which restriction? I'm loading the RSDP table to its architectural correct addres if possible, otherwise it will be l

Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Hi Sameer, On 19/11/17 07:45, Goel, Sameer wrote: On 10/12/2017 10:36 AM, Julien Grall wrote: + +typedef paddr_t phys_addr_t; +typedef paddr_t dma_addr_t; + +/* Alias to Xen device tree helpers */ +#define device_node dt_device_node +#define of_phandle_args dt_phandle_args +#define of_device_id

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 15:14, wrote: > On 20/11/17 14:56, Boris Ostrovsky wrote: >> On 11/20/2017 06:50 AM, Jan Beulich wrote: >> On 20.11.17 at 12:20, wrote: Which restriction? I'm loading the RSDP table to its architectural correct addres if possible, otherwise it will be loaded to th

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream

On 17/11/17 12:10, Jan Beulich wrote: On 16.11.17 at 20:15, wrote: >> Doing so amounts to silent state corruption, and must be avoided. > I think a little more explanation is needed on why the current code > is insufficient. Note specifically this > > for ( i = 0; !err && i < ctxt->count;

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 14:56, Boris Ostrovsky wrote: > On 11/20/2017 06:50 AM, Jan Beulich wrote: > On 20.11.17 at 12:20, wrote: >>> Which restriction? I'm loading the RSDP table to its architectural >>> correct addres if possible, otherwise it will be loaded to the same >>> address as without my patch.

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 14:56, wrote: > On 11/20/2017 06:50 AM, Jan Beulich wrote: > On 20.11.17 at 12:20, wrote: >>> Which restriction? I'm loading the RSDP table to its architectural >>> correct addres if possible, otherwise it will be loaded to the same >>> address as without my patch. So I'm n

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 06:50 AM, Jan Beulich wrote: On 20.11.17 at 12:20, wrote: >> Which restriction? I'm loading the RSDP table to its architectural >> correct addres if possible, otherwise it will be loaded to the same >> address as without my patch. So I'm not adding a restriction, but >> removing

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 11/20/2017 06:20 AM, Juergen Gross wrote: > On 20/11/17 11:57, Andrew Cooper wrote: >> On 20/11/17 10:43, Juergen Gross wrote: >>> On 20/11/17 11:21, Andrew Cooper wrote: On 20/11/17 10:04, Juergen Gross wrote: > On 20/11/17 10:58, Andrew Cooper wrote: >> On 20/11/2017 09:55, Juerge

Re: [Xen-devel] [PATCH v1 0/6] libxl: create standalone vkb device

On Tue, Nov 14, 2017 at 2:39 PM, Oleksandr Grytsov wrote: > On Wed, Nov 1, 2017 at 5:05 PM, Oleksandr Grytsov > wrote: > >> From: Oleksandr Grytsov >> >> Changes since initial: >> * add setting backend-type to xenstore >> * add id field to indentify the vkb device on backend side >> >> Oleksa

Re: [Xen-devel] [PATCH v1 0/5] libxl: add PV sound device

On Tue, Nov 14, 2017 at 2:38 PM, Oleksandr Grytsov wrote: > On Wed, Nov 1, 2017 at 5:04 PM, Oleksandr Grytsov > wrote: > >> From: Oleksandr Grytsov >> >> This patch set adds PV sound device support to xl.cfg and xl. >> See sndif.h for protocol implementation details. >> >> Changes since initial

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record

On 17/11/17 12:15, Jan Beulich wrote: On 16.11.17 at 23:45, wrote: >> Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a >> bug whereby it corrupts the HVM context stream if some, but fewer than the >> maximum number of MSRs are written. >> >> _hvm_init_entry() crea

Re: [Xen-devel] [PATCH for-next] x86/vmx: Drop more PVHv1 remenants

>>> On 20.11.17 at 14:19, wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-next] x86/vmx: Drop more PVHv1 remenants

Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/hvm/vmx/intr.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index 4c0f1c8..eb9b288 100644 --- a/xen/arch/x86/h

Re: [Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

On Mon, Nov 20, 2017 at 12:17:11PM +0100, Juergen Gross wrote: > On 20/11/17 11:49, Wei Liu wrote: > > CC netfront maintainers. > > > > On Mon, Nov 20, 2017 at 11:41:09AM +0100, Eduardo Otubo wrote: > >> When unloading module xen_netfront from guest, dmesg would output > >> warning messages like b

Re: [Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

On Mon, Nov 20, 2017 at 10:55:55AM +, Paul Durrant wrote: > > -Original Message- > > From: Eduardo Otubo [mailto:ot...@redhat.com] > > Sent: 20 November 2017 10:41 > > To: xen-de...@lists.xenproject.org > > Cc: net...@vger.kernel.org; Paul Durrant ; Wei > > Liu ; linux-ker...@vger.kerne

[Xen-devel] [seabios test] 116346: regressions - FAIL

flight 116346 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116346/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not suc

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

flight 116343 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116343/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 115643 test-amd64-amd64-py

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

>>> On 20.11.17 at 12:20, wrote: > Which restriction? I'm loading the RSDP table to its architectural > correct addres if possible, otherwise it will be loaded to the same > address as without my patch. So I'm not adding a restriction, but > removing one. What is "architecturally correct" in PVH

Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

>>> On 20.11.17 at 10:35, wrote: > On Ma, 2017-10-24 at 13:19 +0300, Petre Pircalabu wrote: >> From: Razvan Cojocaru >> >> For the default EPT view we have xc_set_mem_access_multi(), which >> is able to set an array of pages to an array of access rights with >> a single hypercall. However, this f

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 11:57, Andrew Cooper wrote: > On 20/11/17 10:43, Juergen Gross wrote: >> On 20/11/17 11:21, Andrew Cooper wrote: >>> On 20/11/17 10:04, Juergen Gross wrote: On 20/11/17 10:58, Andrew Cooper wrote: > On 20/11/2017 09:55, Juergen Gross wrote: >> On 20/11/17 10:51, Roger Pau M

Re: [Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

On 20/11/17 11:49, Wei Liu wrote: > CC netfront maintainers. > > On Mon, Nov 20, 2017 at 11:41:09AM +0100, Eduardo Otubo wrote: >> When unloading module xen_netfront from guest, dmesg would output >> warning messages like below: >> >> [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 10:43, Juergen Gross wrote: > On 20/11/17 11:21, Andrew Cooper wrote: >> On 20/11/17 10:04, Juergen Gross wrote: >>> On 20/11/17 10:58, Andrew Cooper wrote: On 20/11/2017 09:55, Juergen Gross wrote: > On 20/11/17 10:51, Roger Pau Monné wrote: >> Adding xen-devel, dropped it

Re: [Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

> -Original Message- > From: Eduardo Otubo [mailto:ot...@redhat.com] > Sent: 20 November 2017 10:41 > To: xen-de...@lists.xenproject.org > Cc: net...@vger.kernel.org; Paul Durrant ; Wei > Liu ; linux-ker...@vger.kernel.org; > vkuzn...@redhat.com; cav...@redhat.com; che...@redhat.com; > mga.

Re: [Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

CC netfront maintainers. On Mon, Nov 20, 2017 at 11:41:09AM +0100, Eduardo Otubo wrote: > When unloading module xen_netfront from guest, dmesg would output > warning messages like below: > > [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! > [ 105.236839] deferring g.e. 0x90

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 11:21, Andrew Cooper wrote: > On 20/11/17 10:04, Juergen Gross wrote: >> On 20/11/17 10:58, Andrew Cooper wrote: >>> On 20/11/2017 09:55, Juergen Gross wrote: On 20/11/17 10:51, Roger Pau Monné wrote: > Adding xen-devel, dropped it on my reply.  > > Replying from my

[Xen-devel] [PATCH] xen-netfront: remove warning when unloading module

When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfron

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 10:04, Juergen Gross wrote: > On 20/11/17 10:58, Andrew Cooper wrote: >> On 20/11/2017 09:55, Juergen Gross wrote: >>> On 20/11/17 10:51, Roger Pau Monné wrote: Adding xen-devel, dropped it on my reply.  Replying from my phone, sorry for the formatting.  >>>

[Xen-devel] [distros-debian-sid test] 72466: tolerable FAIL

flight 72466 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72466/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 72441 test-armhf-armhf-armhf-sid-n

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 10:58, Andrew Cooper wrote: > On 20/11/2017 09:55, Juergen Gross wrote: >> On 20/11/17 10:51, Roger Pau Monné wrote: >>> Adding xen-devel, dropped it on my reply.  >>> >>> Replying from my phone, sorry for the formatting.  >>> >>> >>> El 20 nov. 2017 9:35, "Juergen Gross" >>

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/2017 09:55, Juergen Gross wrote: > On 20/11/17 10:51, Roger Pau Monné wrote: >> Adding xen-devel, dropped it on my reply.  >> >> Replying from my phone, sorry for the formatting.  >> >> >> El 20 nov. 2017 9:35, "Juergen Gross" > > escribió: >> >>

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

On 20/11/17 10:51, Roger Pau Monné wrote: > Adding xen-devel, dropped it on my reply.  > > Replying from my phone, sorry for the formatting.  > > > El 20 nov. 2017 9:35, "Juergen Gross" > escribió: > > For PVH domains loading of the ACPI RSDP table i

Re: [Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

Adding xen-devel, dropped it on my reply. Replying from my phone, sorry for the formatting. El 20 nov. 2017 9:35, "Juergen Gross" escribió: For PVH domains loading of the ACPI RSDP table is done via allocating a domain loader segment after having loaded the kernel. This leads to the RSDP table

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

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

Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

On Ma, 2017-10-24 at 13:19 +0300, Petre Pircalabu wrote: > From: Razvan Cojocaru > > For the default EPT view we have xc_set_mem_access_multi(), which > is able to set an array of pages to an array of access rights with > a single hypercall. However, this functionality was lacking for the > altp2m

[Xen-devel] [PATCH for-4.10] libxc: load acpi RSDP table at correct address

For PVH domains loading of the ACPI RSDP table is done via allocating a domain loader segment after having loaded the kernel. This leads to the RSDP table being loaded at an arbitrary guest address instead of the architectural correct address just below 1MB. When using the Linux kernel this is cur