Re: [Xen-devel] [PATCH] x86/EFI: fix build when using GNU Make 4.1

>>> On 02.02.17 at 23:46, wrote: > Since c/s eee5909e9d (x86/EFI: use less crude a way of generating the > build ID) builds have been broken when using GNU Make 4.1. This is > because there are no dependencies on buildid.o and as such GNU Make does > not build it. This adds a

Re: [Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

>>> On 02.02.17 at 20:25, wrote: > @@ -261,6 +265,8 @@ GLOBAL(init_secondary) > sub x20, x19, x0 /* x20 := phys-offset */ > > mov x22, #1/* x22 := is_secondary_cpu */ > +/* Skip zero BSS on secondary CPUs to avoid

Re: [Xen-devel] [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

On 26/01/17 20:41, Boris Ostrovsky wrote: > Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall > page, initialize boot_params, enable early page tables. > > Since this stub is executed before kernel entry point we cannot use > variables in .bss which is cleared by kernel. We

Re: [Xen-devel] [PATCH v3 09/11] fuzz/x86emul: update fuzzer

>>> On 02.02.17 at 18:12, wrote: > On Thu, Feb 02, 2017 at 10:01:46AM -0700, Jan Beulich wrote: >> >>> On 02.02.17 at 17:50, wrote: >> > On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote: >> >> >>> On 01.02.17 at 13:02,

Re: [Xen-devel] [PATCH v3 01/11] x86emul/test: add missing dependency for x86_emulate.o

>>> On 02.02.17 at 18:43, wrote: > On Wed, Feb 01, 2017 at 06:03:20AM -0700, Jan Beulich wrote: >> >>> On 01.02.17 at 13:02, wrote: >> > --- a/tools/tests/x86_emulator/Makefile >> > +++ b/tools/tests/x86_emulator/Makefile >> > @@ -45,7 +45,7 @@

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

flight 105330 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105330/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

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

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

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

flight 105319 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105319/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

[Xen-devel] [linux-linus test] 105295: regressions - trouble: blocked/broken/fail/pass

flight 105295 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 3 host-install(3) broken in 105276 REGR. vs. 59254

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

flight 105313 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105313/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

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

flight 105304 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105304/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

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

flight 105300 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105300/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

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

On Thu, Feb 02, 2017 at 03:12:52PM -0800, Stefano Stabellini wrote: > On Thu, 2 Feb 2017, Edgar E. Iglesias wrote: > > On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote: > > > Hi Edgar, > > > > > > On 31/01/2017 19:06, Edgar E. Iglesias wrote: > > > >On Tue, Jan 31, 2017 at 05:09:53PM

Re: [Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

On 02/02/2017 23:25, Stefano Stabellini wrote: > On Thu, 2 Feb 2017, Julien Grall wrote: >> Commit 146786b "efi: create efi_enabled()" introduced a variable >> efi_flags stored in BSS and used to pass information between the stub >> and Xen. However on ARM, BSS is zeroed after the stub has

Re: [Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

On Thu, 2 Feb 2017, Julien Grall wrote: > Commit 146786b "efi: create efi_enabled()" introduced a variable > efi_flags stored in BSS and used to pass information between the stub > and Xen. However on ARM, BSS is zeroed after the stub has finished to > run and before Xen is started. This means

Re: [Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

On Thu, Feb 02, 2017 at 07:25:32PM +, Julien Grall wrote: > Commit 146786b "efi: create efi_enabled()" introduced a variable > efi_flags stored in BSS and used to pass information between the stub > and Xen. However on ARM, BSS is zeroed after the stub has finished to > run and before Xen is

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

On Thu, 2 Feb 2017, Edgar E. Iglesias wrote: > On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote: > > Hi Edgar, > > > > On 31/01/2017 19:06, Edgar E. Iglesias wrote: > > >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote: > > >>On 31/01/17 16:53, Edgar E. Iglesias wrote: > >

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

On Thu, 2 Feb 2017, Julien Grall wrote: > Hi Roger, > > On 01/02/17 10:55, Roger Pau Monné wrote: > > On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 24/01/17 20:07, Stefano Stabellini wrote: > > > > On Tue, 24 Jan 2017, Julien Grall wrote: > > > >

Re: [Xen-devel] [PATCH] Fix mispelling of length

On Thu, 2 Feb 2017, Julien Grall wrote: > There are quite a few usage of "lenght" instead of "length" in different > part of the repo. Correct it once for all. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > Cc: Ian Jackson

Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

On Thu, Feb 02, 2017 at 04:46:14PM -0600, Doug Goldstein wrote: > On 2/2/17 4:41 PM, Daniel Kiper wrote: > > On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote: > >> Build xen.gz with EFI code. We need this to support multiboot2 > >> protocol on EFI platforms. > >> > >> If we wish to

Re: [Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

On Thu, 2 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 01/02/17 23:23, Stefano Stabellini wrote: > > On Wed, 1 Feb 2017, Julien Grall wrote: > > > On 31/01/2017 23:49, Stefano Stabellini wrote: > > > > On Fri, 27 Jan 2017, Julien Grall wrote: > > > > > On 03/01/17 23:29, Stefano Stabellini

Re: [Xen-devel] [PATCH v14 0/9] x86: multiboot2 protocol support

On Thu, Feb 02, 2017 at 04:27:24PM -0600, Doug Goldstein wrote: > On 2/2/17 4:01 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending fourteenth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed

[Xen-devel] [PATCH] x86/EFI: fix build when using GNU Make 4.1

Since c/s eee5909e9d (x86/EFI: use less crude a way of generating the build ID) builds have been broken when using GNU Make 4.1. This is because there are no dependencies on buildid.o and as such GNU Make does not build it. This adds a dependency so that it is built. Note: This patch is different

Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

On 2/2/17 4:41 PM, Daniel Kiper wrote: > On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote: >> Build xen.gz with EFI code. We need this to support multiboot2 >> protocol on EFI platforms. >> >> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then >> it must contain

Re: [Xen-devel] [PATCH v14 4/9] x86: add multiboot2 protocol support for EFI platforms

On Thu, Feb 02, 2017 at 11:01:14PM +0100, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v14 - suggestions/fixes: > - mark .init.data

Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote: > Build xen.gz with EFI code. We need this to support multiboot2 > protocol on EFI platforms. > > If we wish to load non-ELF file using multiboot (v1) or multiboot2 then > it must contain "linear" (or "flat") representation of code and

[Xen-devel] [PATCH 2/2] libxl: fix dom0 maximum memory setting

When the libxl driver is initialized, it creates a virDomainDef object for dom0 and adds it to the list of domains. Total memory for dom0 was being set from the max_memkb field of libxl_dominfo struct retrieved from libxl, but this field can be set to LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum

[Xen-devel] [PATCH 1/2] libxl: fix reporting of maximum memory

The libxl driver reports different values of maximum memory depending on state of a domain. If inactive, maximum memory value is reported correctly. When active, maximum memory is derived from max_pages value returned by the XEN_SYSCTL_getdomaininfolist sysctl operation. But max_pages can be

[Xen-devel] [PATCH 0/2] libxl: a few domain maximum memory fixes

Patch 1 fixes reporting of domain maximum memory for running domains. When creating a virDomainDef object to represent dom0, max memory was not set correctly, which is fixed by patch2. Jim Fehlig (2): libxl: fix reporting of maximum memory libxl: fix dom0 maximum memory setting

Re: [Xen-devel] [PATCH v14 0/9] x86: multiboot2 protocol support

On 2/2/17 4:01 PM, Daniel Kiper wrote: > Hi, > > I am sending fourteenth version of multiboot2 protocol support for > legacy BIOS and EFI platforms. This patch series release contains > fixes for all known/confirmed issues. > > The final goal is xen.efi binary file which could be loaded by EFI >

[Xen-devel] [PATCH v14 9/9] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v14 5/9] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v14 0/9] x86: multiboot2 protocol support

Hi, I am sending fourteenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS

[Xen-devel] [PATCH v14 4/9] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v14 - suggestions/fixes: - mark .init.data section as writable; by the way we must change similar definition in

[Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v14 7/9] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

[Xen-devel] [PATCH v14 1/9] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v14 6/9] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[Xen-devel] [PATCH v14 3/9] efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v14 8/9] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

Re: [Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

On Thu, 2 Feb 2017, Artem Mygaiev wrote: > Hello Julien, Stefano > > [coverity-related question] > > On 27.01.17 20:11, Julien Grall wrote: > > (CC Artem as ARM coverity admin) > >> Coverity-ID: 1381855 > >> Coverity-ID: 1381853 > > > > I am bit confused... somehow those numbers disappeared from

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

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

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

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

[Xen-devel] [PATCH] Fix mispelling of length

There are quite a few usage of "lenght" instead of "length" in different part of the repo. Correct it once for all. Signed-off-by: Julien Grall --- Cc: Ian Jackson Cc: Wei Liu Cc: George Dunlap

[Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

Commit 146786b "efi: create efi_enabled()" introduced a variable efi_flags stored in BSS and used to pass information between the stub and Xen. However on ARM, BSS is zeroed after the stub has finished to run and before Xen is started. This means that the bits set in efi_flags will be lost. We

[Xen-devel] [PULL 2/5] xen-platform: add support for unplugging NVMe disks...

From: Paul Durrant ...not just IDE and SCSI. This patch allows the Xen tool-stack to fully support of NVMe as an emulated disk type. See [1] for the relevant tool-stack patch discussion. [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html

[Xen-devel] [PULL 3/5] xen-platform: add missing disk unplug option

From: Paul Durrant The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to request unplug of 'aux' disks (which is stated to mean all IDE disks, except the primary master). This patch adds support for that unplug request. NOTE: The semantics of what

[Xen-devel] [PULL 5/5] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()

From: Juergen Gross The error exits of xen_pv_find_xendev() free the new xen-device via g_free() which is wrong. As the xen-device has been initialized as qdev it must be removed via qdev_unplug(). This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6 ("xen: create

[Xen-devel] [PULL 0/5] xen-20170202

tags/xen-20170202 for you to fetch changes up to e9dcbc86d614018923e26e31319b0a54c9e5abac: xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev() (2017-02-02 10:23:53 -0800) Xen 2017/02/02

[Xen-devel] [PULL 1/5] xen-platform: re-structure unplug_disks

From: Paul Durrant The current code is poorly structured and potentially leads to multiple config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS flag is mis-named since it also results in SCSI disks being unplugged. This patch renames the flag and

[Xen-devel] Preparing for GSoC, Outreachy and other Internships (deadline Feb 9th)

Folks, (people who have current projects are CC'ed) I just created https://wiki.xenproject.org/wiki/2017-Summer-Internships and https://wiki.xenproject.org/wiki/Category:Internships as we are planning to apply as mentoring organisation for GSoC 2017 again. To be successful, we need to bring

Re: [Xen-devel] Preparing for GSoC, Outreachy and other Internships (deadline Feb 9th)

Apologies: typo in CC list Regards Lars > On 2 Feb 2017, at 18:36, Lars Kurth wrote: > > Folks, (people who have current projects are CC'ed) > > I just created https://wiki.xenproject.org/wiki/2017-Summer-Internships and >

[Xen-devel] [PULL 4/5] MAINTAINERS: Update xen-devel mailing list address

From: Anthony PERARD Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a428cb2..baea7c7

Re: [Xen-devel] [PATCH v2] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()

On Thu, 2 Feb 2017, Juergen Gross wrote: > On 01/02/17 21:20, Peter Maydell wrote: > > On 1 February 2017 at 19:37, Stefano Stabellini > > wrote: > >> Hi Peter, > >> > >> do you think this is acceptable? > > > > The set of operations here is basically what I suggested >

Re: [Xen-devel] [PATCH] libxl: fix dom0 autoballooning with Xen 4.8

On 02/02/2017 04:42 AM, Wei Liu wrote: I saw this mail but didn't realise it required my input, sorry. I suppose it didn't and I was shamelessly fishing for a review - so you have my apologies :-). But the patch does fix an annoying, easily encountered bug which I'm eager to see resolved in

[Xen-devel] [PATCH v2] xen: sched: harmonize debug dump output among schedulers.

Information we currently print for idle pCPUs is rather useless. Credit2 already stopped showing that, do the same for Credit and RTDS. Also, define a new CPU status dump hook, which is not defined by those schedulers which already dump such info in other ways (e.g., Credit2, which does that

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

flight 105293 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105293/ 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] [PATCH] compat.h: drop COMPAT_HANDLE_PARAM()

On Thu, 2 Feb 2017, Jan Beulich wrote: > The need for 8844ed299a ("x86/dmop: Fix compat_dm_op() ABI") has made > clear that its presence is actively dangerous. At the hypercall entry > points XEN_GUEST_HANDLE_PARAM() should be used anyway (regardless of > whether these are native or compat entry

[Xen-devel] [PATCH] xen: sched: harmonize debug dump output among schedulers.

Information we currently print for idle pCPUs is rather useless. Credit2 already stopped showing that, do the same for Credit and RTDS. Also, define a new CPU status dump hook, which is not defined by those schedulers which already dump such info in other ways (e.g., Credit2, which does that

Re: [Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

On 02/02/2017 11:40 AM, Roger Pau Monné wrote: > On Thu, Feb 02, 2017 at 11:30:19AM -0500, Boris Ostrovsky wrote: >> On 02/02/2017 10:35 AM, Roger Pau Monné wrote: >>> On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote: Make sure they don't use these devices since they are not

Re: [Xen-devel] [PATCH v3 01/11] x86emul/test: add missing dependency for x86_emulate.o

On Wed, Feb 01, 2017 at 06:03:20AM -0700, Jan Beulich wrote: > >>> On 01.02.17 at 13:02, wrote: > > --- a/tools/tests/x86_emulator/Makefile > > +++ b/tools/tests/x86_emulator/Makefile > > @@ -45,7 +45,7 @@ x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h: > > > >

Re: [Xen-devel] [PATCH v3 09/11] fuzz/x86emul: update fuzzer

On Thu, Feb 02, 2017 at 10:01:46AM -0700, Jan Beulich wrote: > >>> On 02.02.17 at 17:50, wrote: > > On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote: > >> >>> On 01.02.17 at 13:02, wrote: > >> > +static int fuzz_read_segment( > >> > +enum

Re: [Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

On Thu, Feb 02, 2017 at 11:30:19AM -0500, Boris Ostrovsky wrote: > On 02/02/2017 10:35 AM, Roger Pau Monné wrote: > > On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote: > >> Make sure they don't use these devices since they are not emulated > >> for unprivileged PVH guest. > > This

Re: [Xen-devel] [PATCH v3 09/11] fuzz/x86emul: update fuzzer

>>> On 02.02.17 at 17:50, wrote: > On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote: >> >>> On 01.02.17 at 13:02, wrote: >> > +static int fuzz_read_segment( >> > +enum x86_segment seg, >> > +struct segment_register *reg, >> > +

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

On Wed, 2017-02-01 at 14:59 +, George Dunlap wrote: > On 26/01/17 16:52, Dario Faggioli wrote: > > > > Scheduling information debug dump for Credit2 is hard > > to read as it contains the same information repeated > > multiple time in different ways. > > > > [..] > > > > Signed-off-by: Dario

Re: [Xen-devel] [PATCH v3 02/11] x86: extract macros to x86-defns.h

On Wed, Feb 01, 2017 at 06:05:23AM -0700, Jan Beulich wrote: > >>> On 01.02.17 at 13:02, wrote: > > --- a/xen/include/asm-x86/processor.h > > +++ b/xen/include/asm-x86/processor.h > > @@ -16,6 +16,8 @@ > > #include > > #endif > > > > +#include "x86-defns.h" > > This

[Xen-devel] [linux-linus test] 105276: regressions - trouble: blocked/broken/fail/pass

flight 105276 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105276/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 3 host-install(3) broken REGR. vs. 59254

Re: [Xen-devel] [PATCH v3 09/11] fuzz/x86emul: update fuzzer

On Thu, Feb 02, 2017 at 05:20:56AM -0700, Jan Beulich wrote: > >>> On 01.02.17 at 13:02, wrote: > > @@ -16,26 +17,78 @@ > > > > #include "x86_emulate.h" > > > > -static unsigned char data[4096]; > > +#define MSR_INDEX_MAX 16 > > + > > +#define SEG_NUM x86_seg_none > > +

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

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

Re: [Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

On 02/02/2017 10:35 AM, Roger Pau Monné wrote: > On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote: >> Make sure they don't use these devices since they are not emulated >> for unprivileged PVH guest. > This description seems weird for what it's actually done. AFAICT you are not >

Re: [Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown event"): > No, handling NULL is not enough. It could well be possible that diskws > is not NULL but then num_disks grows, thus making evdisable_disk_ejects > access out of bound. The additional diskws entries could be

Re: [Xen-devel] [PATCH 1/2] xl: free event in DOMAIN_RESTART_RENAME error path

On Thu, Feb 02, 2017 at 03:46:36PM +, Wei Liu wrote: > Otherwise it is leaked. Found by code inspection. > > Signed-off-by: Wei Liu > --- > Cc: Ian Jackson > Cc: Fatih Acar > > Backport candidate. > --- >

Re: [Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

On Thu, Feb 02, 2017 at 04:05:08PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown > event"): > > On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote: > > > But I think I don't really understand what the original bug is. > > > > The

Re: [Xen-devel] [PATCH] page_alloc: clear nr_bootmem_regions in end_boot_allocator()

>>> On 02.02.17 at 16:41, wrote: > On 02/02/17 15:25, Jan Beulich wrote: >> --- a/xen/common/page_alloc.c >> +++ b/xen/common/page_alloc.c >> @@ -329,13 +329,16 @@ unsigned long __init alloc_boot_pages( >> unsigned long nr_pfns, unsigned long pfn_align) >> { >>

Re: [Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

Wei Liu writes ("Re: [PATCH 2/2] xl: disable events earlier for shutdown event"): > On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote: > > But I think I don't really understand what the original bug is. > > The original bug is that: Ah. > 1. boot a guest with no disks, so diskws is

Re: [Xen-devel] [PATCH] xl: remove stale comment

Wei Liu writes ("Re: [PATCH] xl: remove stale comment"): > On Thu, Feb 02, 2017 at 03:56:03PM +, Ian Jackson wrote: > > Wei Liu writes ("[PATCH] xl: remove stale comment"): > > > case LIBXL_EVENT_TYPE_DISK_EJECT: > > > -/* XXX what is this for? */ > > >

Re: [Xen-devel] [PATCH] xl: remove stale comment

On Thu, Feb 02, 2017 at 03:56:03PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH] xl: remove stale comment"): > > Obvious the DISK_EJECT event is for ejecting removable media. > > The question is... > > > case LIBXL_EVENT_TYPE_DISK_EJECT: > > -/* XXX what is this for?

Re: [Xen-devel] [PATCH] xl: remove stale comment

Wei Liu writes ("[PATCH] xl: remove stale comment"): > Obvious the DISK_EJECT event is for ejecting removable media. The question is... > case LIBXL_EVENT_TYPE_DISK_EJECT: > -/* XXX what is this for? */ > libxl_cdrom_insert(ctx, domid, >u.disk_eject.disk, NULL);

Re: [Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

On Thu, Feb 02, 2017 at 03:52:41PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH 2/2] xl: disable events earlier for shutdown event"): > > We need to disable event machinery when the guest shuts down. It > > doesn't really matter where we disable it as long as it is within the > > branch

[Xen-devel] [PATCH] xl: remove stale comment

Obvious the DISK_EJECT event is for ejecting removable media. Signed-off-by: Wei Liu --- Cc: Ian Jackson Ian, feel free to tell me that I'm wrong... --- tools/libxl/xl_cmdimpl.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

Wei Liu writes ("[PATCH 2/2] xl: disable events earlier for shutdown event"): > We need to disable event machinery when the guest shuts down. It > doesn't really matter where we disable it as long as it is within the > branch for shutdown event. I don't think this is necessary. My intent was

Re: [Xen-devel] [PATCH] xen-netfront: Improve error handling during initialization

On 02/02/2017 09:54 AM, Ross Lagerwall wrote: > On 02/01/2017 06:54 PM, Boris Ostrovsky wrote: >> On 02/01/2017 10:50 AM, Ross Lagerwall wrote: >>> Improve error handling during initialization. This fixes a crash when >>> running out of grant refs when creating many queues across many >>> netdevs.

[Xen-devel] [PATCH 1/2] xl: free event in DOMAIN_RESTART_RENAME error path

Otherwise it is leaked. Found by code inspection. Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Fatih Acar Backport candidate. --- tools/libxl/xl_cmdimpl.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Xen-devel] [PATCH 0/2] xl: event machinery fixes

Wei Liu (2): xl: free event in DOMAIN_RESTART_RENAME error path xl: disable events earlier for shutdown event tools/libxl/xl_cmdimpl.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) -- 2.11.0 ___ Xen-devel mailing list

[Xen-devel] [PATCH 2/2] xl: disable events earlier for shutdown event

We need to disable event machinery when the guest shuts down. It doesn't really matter where we disable it as long as it is within the branch for shutdown event. Move the code snippet before handle_domain_death, so that d_config is not yet updated and we have the correct ->num_disks. And the

Re: [Xen-devel] [PATCH] page_alloc: clear nr_bootmem_regions in end_boot_allocator()

On 02/02/17 15:25, Jan Beulich wrote: > ... to make alloc_boot_pages() fail for late callers. Don't rely on > reaching the BOOT_BUG_ON(1) near the end of that function though, but > instead make this situation easier to distinguish from actual > allocation failures by adding an explicit check. > >

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

On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote: > Or maybe we could avoid mapping the doorbell in the guest and let Xen > receive an SMMU abort. When receiving the SMMU abort, Xen could sanitize the > value and write into the real MSI doorbell. Not sure if it would works > thought.

Re: [Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote: > Make sure they don't use these devices since they are not emulated > for unprivileged PVH guest. This description seems weird for what it's actually done. AFAICT you are not really preventing the guest from using the PIC or the IO

Re: [Xen-devel] several domU crashes after 4.1->4.8 live migration

On Thu, Feb 2, 2017 at 1:30 PM, Vincent Legout wrote: > On Thu, Feb 02, 2017 at 12:05:09PM +, Andrew Cooper wrote : >> On 02/02/17 07:58, Vincent Legout wrote: >> > Hello, >> > >> > We had some issues after live migrating several domU from xen 4.1 to xen >> > 4.8. We

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

flight 105289 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105289/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 6 xen-boot fail REGR. vs. 105218

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

>>> On 27.01.17 at 20:48, wrote: > At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote: >> - vmx_set_segment_register() should initialize the TSS every >> time (including setting the I/O bitmap address to no lower >> than 32) > > Probably to no lower than 136, to avoid

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

On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote: > Hi Edgar, > > On 31/01/2017 19:06, Edgar E. Iglesias wrote: > >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote: > >>On 31/01/17 16:53, Edgar E. Iglesias wrote: > >>>On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall

Re: [Xen-devel] [xen-unstable-smoke test] 105283: regressions - trouble: broken/fail/pass

On 02/02/2017 09:52 AM, Jan Beulich wrote: On 02.02.17 at 15:09, wrote: >> On 02/02/17 13:56, osstest service owner wrote: >>> flight 105283 xen-unstable-smoke real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/105283/ >>> >>> Regressions :-( >>> >>>

[Xen-devel] [PATCH] page_alloc: clear nr_bootmem_regions in end_boot_allocator()

... to make alloc_boot_pages() fail for late callers. Don't rely on reaching the BOOT_BUG_ON(1) near the end of that function though, but instead make this situation easier to distinguish from actual allocation failures by adding an explicit check. While there, make the iteration variable

Re: [Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

On 26/01/17 20:41, Boris Ostrovsky wrote: > Make sure they don't use these devices since they are not emulated > for unprivileged PVH guest. > > Also don't initialize hypercall page for them in init_hvm_pv_info() > since this has already been done. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2] VT-d/RMRR: Adjust the return values of register_one_rmrr()

>>> On 02.02.17 at 16:08, wrote: > Adjust/manage the return values of register_one_rmrr() such that new > callers log errors for non-debug builds too, while not affecting the > behavior of the original callers. > > Signed-off-by: Venu Busireddy

[Xen-devel] [PATCH v2] VT-d/RMRR: Adjust the return values of register_one_rmrr()

Adjust/manage the return values of register_one_rmrr() such that new callers log errors for non-debug builds too, while not affecting the behavior of the original callers. Signed-off-by: Venu Busireddy --- xen/drivers/passthrough/vtd/dmar.c | 11 +++ 1 file

Re: [Xen-devel] [PATCH] xen-netfront: Improve error handling during initialization

On 02/01/2017 06:54 PM, Boris Ostrovsky wrote: On 02/01/2017 10:50 AM, Ross Lagerwall wrote: Improve error handling during initialization. This fixes a crash when running out of grant refs when creating many queues across many netdevs. * Delay timer creation so that if initializing a queue

Re: [Xen-devel] [xen-unstable-smoke test] 105283: regressions - trouble: broken/fail/pass

>>> On 02.02.17 at 15:09, wrote: > On 02/02/17 13:56, osstest service owner wrote: >> flight 105283 xen-unstable-smoke real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/105283/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >>

Re: [Xen-devel] [xen-unstable-smoke test] 105283: regressions - trouble: broken/fail/pass

On 02/02/17 13:56, osstest service owner wrote: > flight 105283 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/105283/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

  1   2   >