[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

[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] [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] 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

[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 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

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] [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] [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

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] 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] 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

[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:

[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 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

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] [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] 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

[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

[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.

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 >

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] [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

[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 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

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

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

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] [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

[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] [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

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

Hello, We had some issues after live migrating several domU from xen 4.1 to xen 4.8. We migrated around 200 domU and 5 crashed, from a few hours up to several days after the migration. All the domU had more than 1 year of uptime, and for example one crashed several days after the migration during

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

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 > in review of v1, so I think it is the right thing. > OTOH

Re: [Xen-devel] [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen

On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote: > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for > disposable private objects") introduced a regression for the kernel > running as Xen dom0: when switching to graphics mode a GPU HANG > occurred. > > Reason

[Xen-devel] [xen-unstable test] 105258: tolerable FAIL

flight 105258 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105258/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 105224 Regressions which are regarded

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

flight 105236 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105236/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254

[Xen-devel] [libvirt test] 105262: tolerable FAIL - PUSHED

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

[Xen-devel] [PATCH] drm/i915: fix i915 running as dom0 under Xen

Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for disposable private objects") introduced a regression for the kernel running as Xen dom0: when switching to graphics mode a GPU HANG occurred. Reason seems to be a missing adaption similar to that done in commit 7453c549f5f648

Re: [Xen-devel] [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen

On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote: > On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote: > > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for > > disposable private objects") introduced a regression for the kernel > > running as Xen dom0:

[Xen-devel] [distros-debian-wheezy test] 68505: tolerable trouble: broken/fail/pass

flight 68505 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68505/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-wheezy-netboot-pvgrub 9 debian-di-install fail blocked in 68487 Tests

Re: [Xen-devel] [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_rmrr()

>>> On 01.02.17 at 10:44, wrote: On 31.01.17 at 18:00, wrote: >> That brings up this question. Do we want to disable VT-d if the PCIe >> device specified via ACPI cannot be detected? We do so if the address >> range is incorrectly specified. If

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] 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 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 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

[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] [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

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

>>> On 01.02.17 at 18:51, wrote: > --- a/xen/drivers/passthrough/vtd/dmar.c > +++ b/xen/drivers/passthrough/vtd/dmar.c > @@ -840,13 +841,13 @@ static int __init acpi_parse_dmar(struct > acpi_table_header *table) > entry_header->type); >

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

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

Re: [Xen-devel] Ping: [PATCH v2 RESEND] x86/time: correctly honor late clearing of TSC related feature flags

On 05/01/17 14:42, Jan Beulich wrote: On 20.12.16 at 13:35, wrote: >> Once we have ever had cause to use time_calibration_tsc_rendezvous, >> there is no situation where it is safe to switch back to >> time_calibration_std_rendezvous, as the choice to use >>

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

On Thu, Feb 02, 2017 at 04:22:53AM -0700, Jan Beulich wrote: > >>> On 01.02.17 at 19:21, wrote: > > On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote: > >> Hi Dario, > >> > >> On 25/01/17 16:00, Dario Faggioli wrote: > >> > On Wed, 2017-01-25 at 12:38 +,

Re: [Xen-devel] [PATCH] xl: Fix segfault on domain reboot

On 02/02/2017 12:25, Wei Liu wrote: > > You didn't check if diskws_new is NULL. > > Actually you can just use xrealloc here. > You're right, using xrealloc is much better here. > > It seems that you've used "xl config-update" to update the domain > configuration. Is this correct? > > But

[Xen-devel] [PATCH] xl: Make the devid attribute manually settable for nics

This permits to have control over the devid attribute when attaching new nics. It may become useful if one has its own nic indexing somewhere else than xl/xenstore. Signed-off-by: Fatih Acar Signed-off-by: Nikita Kozlov Signed-off-by: Vincent

Re: [Xen-devel] [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen

On Thu, Feb 02, 2017 at 12:11:29PM +, Tvrtko Ursulin wrote: > > On 02/02/2017 09:47, Juergen Gross wrote: > >Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for > >disposable private objects") introduced a regression for the kernel > >running as Xen dom0: when switching to

Re: [Xen-devel] [PATCH] xl: Fix assertion on domain reboot with new configuration

On Mon, Jan 30, 2017 at 03:33:18PM +0100, Fatih Acar wrote: > libxl_domain_build_info_dispose is not resetting the type field to > LIBXL_DOMAIN_TYPE_INVALID. > Instead, it is memseting the struct to 0 thus when > libxl_domain_build_info_init_type is called > after a dispose on the same struct,

[Xen-devel] [PATCH] compat.h: drop COMPAT_HANDLE_PARAM()

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 points), and passing around handles internally

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

On Thu, 2017-02-02 at 04:22 -0700, Jan Beulich wrote: > On 01.02.17 at 19:21, wrote: > > On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote: > > > Yeah, even the tiny RCU code is quite complex :/. I've looked at > > > our RCUcode and noticed there is a link in

Re: [Xen-devel] [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen

On 02/02/2017 09:47, Juergen Gross wrote: Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for disposable private objects") introduced a regression for the kernel running as Xen dom0: when switching to graphics mode a GPU HANG occurred. Reason seems to be a missing adaption

Re: [Xen-devel] [PATCH v2] libs/gnttab: add FreeBSD handlers for the grant-table user-space device

On Wed, Feb 01, 2017 at 05:44:55PM +, Roger Pau Monne wrote: [...] > diff --git a/tools/libs/gnttab/private.h b/tools/libs/gnttab/private.h > index d6c5594..1416194 100644 > --- a/tools/libs/gnttab/private.h > +++ b/tools/libs/gnttab/private.h > @@ -4,6 +4,16 @@ > #include > #include > >

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

>>> On 01.02.17 at 19:21, wrote: > On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote: >> Hi Dario, >> >> On 25/01/17 16:00, Dario Faggioli wrote: >> > On Wed, 2017-01-25 at 12:38 +, Julien Grall wrote: >> > > On 25/01/17 11:10, Dario Faggioli wrote: >> > And a

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

On Thu, Feb 2, 2017 at 7:58 AM, Vincent Legout wrote: > Hello, > > We had some issues after live migrating several domU from xen 4.1 to xen > 4.8. We migrated around 200 domU and 5 crashed, from a few hours up to > several days after the migration. All the domU had more

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

On Thu, Feb 02, 2017 at 11:22:02AM +, George Dunlap wrote : > On Thu, Feb 2, 2017 at 7:58 AM, Vincent Legout > wrote: > > Hello, > > > > We had some issues after live migrating several domU from xen 4.1 to xen > > 4.8. We migrated around 200 domU and 5 crashed, from

Re: [Xen-devel] [PATCH 3/4] x86/vvmx: correctly emulate VMWRITE

On 02/02/17 12:52, Jan Beulich wrote: On 31.01.17 at 12:20, wrote: >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -264,7 +264,7 @@ u64 get_vvmcs_real(const struct vcpu *v, u32 encoding) >> return virtual_vmcs_vmread(v,

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

Hi Dario, On 02/02/17 12:51, Dario Faggioli wrote: On Thu, 2017-02-02 at 12:18 +, Julien Grall wrote: Dario, are you going to look into the issue? Or shall I try to write a patch for it? I'd be up for looking into this. BUT, I'm travelling this weekend, and am probably going to be busy

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

On Thu, 2017-02-02 at 13:26 +, Julien Grall wrote: > On 02/02/17 12:51, Dario Faggioli wrote: > > So, I expect to be able to do something useful only, let's stay, > > from > > Mon 13th. If that's ok, do sign me up. If you're more in a hurry, > > feel > > free to beat me. :-) > > I have plenty

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

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: test-amd64-amd64-xl-qemuu-debianhvm-i386 6 xen-boot fail REGR. vs. 105218

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

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 wrote: So we have to worry about SPIs and LPIs (thought they are not

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

>>> 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 > + > +struct input_struct { > +unsigned long cr[5]; > +uint64_t

Re: [Xen-devel] [PATCH 3/4] x86/vvmx: correctly emulate VMWRITE

>>> On 31.01.17 at 12:20, wrote: > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -264,7 +264,7 @@ u64 get_vvmcs_real(const struct vcpu *v, u32 encoding) > return virtual_vmcs_vmread(v, encoding); > } > > -void set_vvmcs_virtual(void

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

On Thu, 2017-02-02 at 12:18 +, Julien Grall wrote: > Dario, are you going to look into the issue? Or shall I try to write > a  > patch for it? > I'd be up for looking into this. BUT, I'm travelling this weekend, and am probably going to be busy next week (sorry). So, I expect to be able to

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

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 migrated around 200 domU and 5 crashed, from a few hours up to > several days after the migration. All the domU had more than 1 year of > uptime, and for example

Re: [Xen-devel] [PATCH] xl: Fix assertion on domain reboot with new configuration

On Thu, Feb 02, 2017 at 11:26:16AM +, Wei Liu wrote: > On Mon, Jan 30, 2017 at 03:33:18PM +0100, Fatih Acar wrote: > > libxl_domain_build_info_dispose is not resetting the type field to > > LIBXL_DOMAIN_TYPE_INVALID. > > Instead, it is memseting the struct to 0 thus when > >

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

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: whilst for Device Tree the segment number is not available. So Xen needs to

Re: [Xen-devel] [PATCH 2/4] x86/vmx: improve __vmread_safe()

>>> On 31.01.17 at 12:20, wrote: > --- a/xen/include/asm-x86/hvm/vmx/vmx.h > +++ b/xen/include/asm-x86/hvm/vmx/vmx.h > @@ -401,32 +401,27 @@ static always_inline void __vmwrite(unsigned long > field, unsigned long value) > ); > } > > -static inline bool_t

Re: [Xen-devel] [PATCH] xl: Make the devid attribute manually settable for nics

On Thu, Feb 02, 2017 at 01:20:49PM +0100, Fatih Acar wrote: > This permits to have control over the devid attribute when attaching new nics. > It may become useful if one has its own nic indexing somewhere else than > xl/xenstore. > > Signed-off-by: Fatih Acar >

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

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 migrated around 200 domU and 5 crashed, from a few hours up to > > several days after

Re: [Xen-devel] [PATCH] xl: Fix segfault on domain reboot

On Mon, Jan 30, 2017 at 03:31:49PM +0100, Fatih Acar wrote: > If we have no disk attached at startup, diskws is left unallocated > but `d_config.num_disks` may change if we attach a disk later. > When a domain is rebooted `evdisable_disk_ejects` is called > this will later result in a segfault if

Re: [Xen-devel] [PATCH] x86emul: correct behavior for single iteration REP INS/OUTS

On 01/02/17 10:59, Jan Beulich wrote: > The initial operation done on these paths may raise an exception (for > ->read_io() that's possible only on the PV path, when the I/O port > access check has been deferred). We have to suppress put_rep_prefix() > updating rCX in that case. From an abstract

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

I saw this mail but didn't realise it required my input, sorry. On Wed, Feb 01, 2017 at 04:00:54PM -0700, Jim Fehlig wrote: > Jim Fehlig wrote: > > xen.git commit 57f8b13c changed several of the libxl memory > > get/set functions to take 64 bit parameters. The libvirt > > libxl driver still uses

Re: [Xen-devel] [PATCH] compat.h: drop COMPAT_HANDLE_PARAM()

On Thu, Feb 02, 2017 at 04:45:37AM -0700, 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

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

Hi, On 02/02/17 11:53, Wei Liu wrote: On Thu, Feb 02, 2017 at 04:22:53AM -0700, Jan Beulich wrote: On 01.02.17 at 19:21, wrote: On Tue, Jan 31, 2017 at 04:30:50PM +, Julien Grall wrote: Hi Dario, On 25/01/17 16:00, Dario Faggioli wrote: On Wed, 2017-01-25 at 12:38

Re: [Xen-devel] [PATCH 1/4] x86/vmx: introduce __vmwrite_safe()

>>> On 31.01.17 at 12:20, wrote: > --- a/tools/tests/x86_emulator/x86_emulate.h > +++ b/tools/tests/x86_emulator/x86_emulate.h > @@ -46,6 +46,12 @@ > #define MMAP_SZ 16384 > bool emul_test_make_stack_executable(void); > > +#ifdef __GCC_ASM_FLAG_OUTPUTS__ > +# define

[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] [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] [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] 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

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

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 the main Coverity > page. Which means Coverity think they

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, >>

[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

  1   2   >