Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 9:49:50 PM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> > It is tricky to do so safely, because at this stage almost nothing >of the C >> > execution environment has been set up. > >Yeah - but we do have a fair amount

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

flight 102789 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102789/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 102722 Regressions

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

* Boris Ostrovsky wrote: > > It is tricky to do so safely, because at this stage almost nothing of the C > > execution environment has been set up. Yeah - but we do have a fair amount of early C code though. > I can still give it a try but I'd rather not tie it to

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

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

[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-multivcpu

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-multivcpu testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [linux-4.1 test] 102778: regressions - FAIL

flight 102778 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102778/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737

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

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

Re: [Xen-devel] [PATCH] xen/arm: Fix misplaced parentheses for PSCI version check

On Thu, 1 Dec 2016, Wei Liu wrote: > On Wed, Nov 30, 2016 at 11:16:49AM -0800, Stefano Stabellini wrote: > > On Wed, 30 Nov 2016, Julien Grall wrote: > > > Hi Artem, > > > > > > On 30/11/16 13:53, Artem Mygaiev wrote: > > > > Fix misplaced parentheses for PSCI version check > > > > > > > >

Re: [Xen-devel] [PATCH v1] arm/irq: Reorder check when the IRQ is already used by someone

On Fri, 2 Dec 2016, Oleksandr Tyshchenko wrote: > Call irq_get_domain for the IRQ we are interested in > only after making sure that it is the guest IRQ to avoid > ASSERT(test_bit(_IRQ_GUEST, >status)) triggering. > > Signed-off-by: Oleksandr Tyshchenko >

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 2 Dec 2016, Andre Przywara wrote: > Hi, > > sorry for chiming in late > > I've been spending some time thinking about this, and I think we can in > fact get away without ever propagating command from domains to the host. > > I made a list of all commands that possible require host

[Xen-devel] [linux-3.18 test] 102773: regressions - FAIL

flight 102773 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102773/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675

Re: [Xen-devel] [PATCH v3 for-4.8] tools/configure: fix pkg-config install path for FreeBSD

Thanks! -- alex On Fri, 02 Dec 2016 19:16:33 +0300 Roger Pau Monne roger@citrix.com wrote On Sat, Nov 19, 2016 at 03:59:08PM +0300, Alexander Nusov wrote: Hello, I've reinstalled xen from ports on FreeBSD-11.0 and it seems xenlight.pc is not being

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

On Fri, 2 Dec 2016, Dario Faggioli wrote: > On Thu, 2016-12-01 at 15:14 -0800, Stefano Stabellini wrote: > > On Thu, 1 Dec 2016, Dario Faggioli wrote: > > > > > > On Tue, 2016-11-29 at 15:34 -0800, Stefano Stabellini wrote: > > > >  > > > > ring-ref- (ring-ref-0, ring-ref-1, etc) > > > > > >

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

On Fri, 2 Dec 2016, David Vrabel wrote: > On 02/12/16 00:29, Stefano Stabellini wrote: > > On Wed, 30 Nov 2016, David Vrabel wrote: > >> On 29/11/16 23:34, Stefano Stabellini wrote: > >>> > >>> The producer (the backend for **in**, the frontend for **out**) writes to > >>> the > >>> array in the

[Xen-devel] [xen-unstable-smoke test] 102812: tolerable all pass - PUSHED

flight 102812 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102812/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

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

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

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 12/02/2016 06:44 AM, Andrew Cooper wrote: > On 02/12/16 00:35, Andy Lutomirski wrote: >> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't >> guaranteed to serialize. (Even CPUID isn't *really* guaranteed to >> serialize on Xen PV, but, in practice, any trap it generates will >>

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

flight 102766 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102766/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 10 guest-startfail REGR. vs. 102741

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On 12/02/2016 12:52 PM, h...@zytor.com wrote: > On December 2, 2016 8:08:55 AM PST, Ingo Molnar wrote: >> * Boris Ostrovsky wrote: >> >>> On 12/02/2016 04:45 AM, Ingo Molnar wrote: * Boris Ostrovsky wrote: >

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Dec 2, 2016 10:48 AM, "Boris Ostrovsky" wrote: > > On 12/02/2016 06:44 AM, Andrew Cooper wrote: > > On 02/12/16 00:35, Andy Lutomirski wrote: > >> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't > >> guaranteed to serialize. (Even CPUID isn't *really*

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

On Fri, 2 Dec 2016, Lars Kurth wrote: > On 01/12/2016 22:36, "Stefano Stabellini" wrote: > > >On Thu, 1 Dec 2016, Ian Jackson wrote: > >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision > >>making; some new roles and minor changes"): > >> > Maybe

Re: [Xen-devel] [PATCH v2 4/4] 9pfs: introduce init_out/in_iov_from_pdu

On Fri, 2 Dec 2016, Greg Kurz wrote: > On Mon, 28 Nov 2016 13:27:24 -0800 > Stefano Stabellini wrote: > > > Not all 9pfs transports share memory between request and response. For > > those who don't, it is necessary to know how much memory is required in > > the response.

[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-freebsd10-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 12/02/2016 06:44 AM, Andrew Cooper wrote: > On 02/12/16 00:35, Andy Lutomirski wrote: >> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't >> guaranteed to serialize. (Even CPUID isn't *really* guaranteed to >> serialize on Xen PV, but, in practice, any trap it generates will >>

[Xen-devel] [xen-unstable-smoke test] 102803: trouble: broken/pass

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

[Xen-devel] [xen-4.4-testing test] 102769: regressions - FAIL

flight 102769 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102769/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs. 102521

Re: [Xen-devel] ARM: Request backport for Xen 4.6 and Xen 4.5

On 02/12/16 07:19, Jan Beulich wrote: On 01.12.16 at 18:58, wrote: >> While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to >> boot on the Foundation Model [1]. >> >> The Foundation Model is a free model provided by ARM for ARMv8 which is >> supported

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On December 2, 2016 8:08:55 AM PST, Ingo Molnar wrote: > >* Boris Ostrovsky wrote: > >> On 12/02/2016 04:45 AM, Ingo Molnar wrote: >> > * Boris Ostrovsky wrote: >> > >> >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote: >>

Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

On Fri, Dec 02, 2016 at 10:20:59AM -0700, Jan Beulich wrote: > >>> On 02.12.16 at 14:48, wrote: > > @@ -436,7 +439,7 @@ struct acpi_20_slit { > > * Table revision numbers. > > */ > > #define ACPI_2_0_RSDP_REVISION 0x02 > > -#define ACPI_2_0_FADT_REVISION 0x04 > >

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:23, Andy Lutomirski wrote: > On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper > wrote: >> On 02/12/16 17:07, Andy Lutomirski wrote: >>> On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: On 02/12/16 00:35, Andy Lutomirski wrote:

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Fri, Dec 2, 2016 at 9:16 AM, Andrew Cooper wrote: > On 02/12/16 17:07, Andy Lutomirski wrote: >> On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: >>> On 02/12/16 00:35, Andy Lutomirski wrote: On Xen PV, CPUID is likely to trap, and Xen

Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

>>> On 02.12.16 at 14:48, wrote: > @@ -436,7 +439,7 @@ struct acpi_20_slit { > * Table revision numbers. > */ > #define ACPI_2_0_RSDP_REVISION 0x02 > -#define ACPI_2_0_FADT_REVISION 0x04 > +#define ACPI_2_0_FADT_REVISION 0x05 Do we really want to make this change

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On 02/12/16 17:07, Andy Lutomirski wrote: > On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: >> On 02/12/16 00:35, Andy Lutomirski wrote: >>> On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't >>> guaranteed to serialize. (Even CPUID isn't *really* guaranteed

Re: [Xen-devel] [PATCH v2 1/4] tools/libacpi: add _FADT_ to the FADT boot flags definitions

>>> On 02.12.16 at 14:48, wrote: > --- a/tools/libacpi/acpi2_0.h > +++ b/tools/libacpi/acpi2_0.h > @@ -227,9 +227,8 @@ struct acpi_20_fadt { > /* > * FADT Boot Architecture Flags. > */ > -#define ACPI_LEGACY_DEVICES (1 << 0) > -#define ACPI_8042 (1 << 1) > - >

Re: [Xen-devel] [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation

On Dec 2, 2016 3:44 AM, "Andrew Cooper" wrote: > > On 02/12/16 00:35, Andy Lutomirski wrote: > > On Xen PV, CPUID is likely to trap, and Xen hypercalls aren't > > guaranteed to serialize. (Even CPUID isn't *really* guaranteed to > > serialize on Xen PV, but, in

[Xen-devel] [PATCH v1] arm/irq: Reorder check when the IRQ is already used by someone

Call irq_get_domain for the IRQ we are interested in only after making sure that it is the guest IRQ to avoid ASSERT(test_bit(_IRQ_GUEST, >status)) triggering. Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Andrii Anisov ---

[Xen-devel] [OSSTEST v1.1 PATCH 2.1/3] Executive database: Handle 40001 "SERIALIZATION FAILURE" too

This can happen if the locks are removed, which we are about to do. Signed-off-by: Ian Jackson --- Osstest/JobDB/Executive.pm | 3 ++- tcl/JobDB-Executive.tcl| 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Osstest/JobDB/Executive.pm

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

Hi, sorry for chiming in late I've been spending some time thinking about this, and I think we can in fact get away without ever propagating command from domains to the host. I made a list of all commands that possible require host ITS command propagation. There are two groups: 1:

Re: [Xen-devel] [PATCH v3 for-4.8] tools/configure: fix pkg-config install path for FreeBSD

On Sat, Nov 19, 2016 at 03:59:08PM +0300, Alexander Nusov wrote: > Hello, > > > > I've reinstalled xen from ports on FreeBSD-11.0 > > and it seems xenlight.pc is not being installed to > /usr/local/libdata/pkgconfig/ directory. > > > > root@controller:/usr/ports/devel/libvirt # find /usr/

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

* Boris Ostrovsky wrote: > On 12/02/2016 04:45 AM, Ingo Molnar wrote: > > * Boris Ostrovsky wrote: > > > >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote: > >>> > >>> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote: > From: Matt

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

On 01/12/2016 22:36, "Stefano Stabellini" wrote: >On Thu, 1 Dec 2016, Ian Jackson wrote: >> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision >>making; some new roles and minor changes"): >> > Maybe Ian has some views on what is better from a

Re: [Xen-devel] megaraid_sas regression in linux-3.18 [and 1 more messages]

On Fri, Dec 02, 2016 at 02:36:22PM +, Ian Jackson wrote: > Sumit Saxena writes ("RE: megaraid_sas regression in linux-3.18"): > > There was regression caused because of this commit. Please pick below > > commit which fixes the regression- > > > > commit

[Xen-devel] [xen-unstable-smoke test] 102796: tolerable all pass - PUSHED

flight 102796 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102796/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] ARM PCI Pass through Design Draft 5

- | PCI Pass-through in Xen ARM | - manish.ja...@cavium.com - Draft-5

[Xen-devel] [PATCH v2 30/35] libxl/libxl_save_callout.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_save_callout.c | 8 1 file changed, 4 insertions(+), 4

[Xen-devel] [PATCH v2 32/35] libxl/libxl_vnuma.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_vnuma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Xen-devel] [PATCH v2 24/35] libxl/libxl_no_colo.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_no_colo.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Xen-devel] [PATCH v2 16/35] libxl/libxl_dom_save.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_dom_save.c | 29 +++-- 1 file changed, 15

[Xen-devel] [PATCH v2 35/35] libxl/libxl_xshelp.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_xshelp.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Xen-devel] [distros-debian-jessie test] 68149: tolerable all pass

flight 68149 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68149/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail never pass

[Xen-devel] [PATCH v2 25/35] libxl/libxl_pci.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_pci.c | 153 +--- 1

[Xen-devel] [PATCH v2 29/35] libxl/libxl_remus.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_remus.c | 27 ++- 1 file changed, 14

[Xen-devel] [PATCH v2 08/35] libxl/libxl_colo_nic.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo_nic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Xen-devel] [PATCH v2 18/35] libxl/libxl_freebsd.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_freebsd.c | 8 +--- 1 file changed, 5 insertions(+), 3

[Xen-devel] [PATCH v2 27/35] libxl/libxl_pvusb.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_usb.c | 57 ++--- 1

[Xen-devel] [PATCH v2 23/35] libxl/libxl_nic.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_nic.c | 9 + 1 file changed, 5 insertions(+), 4

[Xen-devel] [PATCH v2 03/35] libxl.c: switch to LOG*D use (refactored messages)

From: Cedric Bosdonnat Use LOG*D functions to output the domain ID in logs as much as possible. This will help consumer code sorting the logs by domain. This commit, only changes LOG*() into LOG*D() and adds a domid parameter. The message of these LOG* calls has been

[Xen-devel] [PATCH v2 07/35] libxl/libxl_colo.h: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Xen-devel] [PATCH v2 34/35] libxl/libxl_x86.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_x86.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

[Xen-devel] [PATCH v2 28/35] libxl/libxl_qmp.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_qmp.c | 56 - 1

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

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

[Xen-devel] [PATCH v2 04/35] libxl.c: switch to LOG*D use

From: Cedric Bosdonnat Use LOG*D functions to output the domain ID in logs as much as possible. This will help consumer code sorting the logs by domain. This commit includes all LOG* to LOG*D changes where the domain ID is not just a domid variable. We want the domain ID

[Xen-devel] [PATCH v2 19/35] libxl/libxl_internal.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_internal.c | 29 ++--- 1 file changed, 14

[Xen-devel] [PATCH v2 33/35] libxl/libxl_vtpm.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_vtpm.c | 8 1 file changed, 4 insertions(+), 4

[Xen-devel] [PATCH v2 31/35] libxl/libxl_stream_write.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_stream_write.c | 10 +- 1 file changed, 5 insertions(+),

[Xen-devel] [PATCH v2 22/35] libxl/libxl_netbuffer.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_netbuffer.c | 43 --- 1

[Xen-devel] [PATCH v2 26/35] libxl/libxl_psr.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_psr.c | 12 ++-- 1 file changed, 6 insertions(+), 6

[Xen-devel] [PATCH v2 20/35] libxl/libxl_linux.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_linux.c | 23 ++- 1 file changed, 14

[Xen-devel] [PATCH v2 00/35] libxl LOG*D functions

Hey all, Here is v2 addressing Wei's comments on patch #1. The 3 libxl.c patches haven't been merged, but the commit message of the first one has been slightly rewritten to help understanding the reason of the split. Note: I added Wei Liu's ACK on all patches Cedric Bosdonnat (35): libxl: add

[Xen-devel] [PATCH v2 17/35] libxl/libxl_dom_suspend.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_dom_suspend.c | 45 - 1

[Xen-devel] [PATCH v2 06/35] libxl/libxl_checkpoint_device.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_checkpoint_device.c | 14 +++--- 1 file changed, 7

[Xen-devel] [PATCH v2 12/35] libxl/libxl_colo_save.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo_save.c | 49 ++- 1

[Xen-devel] [PATCH v2 15/35] libxl/libxl_dm.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_dm.c | 111 ++--- 1

[Xen-devel] [PATCH v2 10/35] libxl/libxl_colo_qdisk.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo_qdisk.c | 2 +- 1 file changed, 1 insertion(+), 1

[Xen-devel] [PATCH v2 01/35] libxl: add LIBXL_LOGD_* and LOG*D function families.

From: Cedric Bosdonnat These functions should be used to log messages when the domain id is known. libxl__log will now prepend the log message by "Domain %PRIu32:" if the domain id is a valid one. This aims at helping consumers filter logs on domain IDs. Signed-off-by:

[Xen-devel] [PATCH v2 05/35] libxl/libxl_bootloader.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D functions to output the domain ID in logs as much as possible. This will help consumer code sorting the logs by domain. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu ---

[Xen-devel] [PATCH v2 21/35] libxl/libxl_netbsd.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_netbsd.c | 9 ++--- 1 file changed, 6 insertions(+), 3

[Xen-devel] [PATCH v2 13/35] libxl/libxl_create.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_create.c | 119 +++-- 1

[Xen-devel] [PATCH v2 14/35] libxl/libxl_device.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_device.c | 70 -- 1

[Xen-devel] [PATCH v2 09/35] libxl/libxl_colo_proxy.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo_proxy.c | 24 1 file changed, 12

[Xen-devel] [PATCH v2 11/35] libxl/libxl_colo_restore.c: used LOG*D functions

From: Cedric Bosdonnat Use LOG*D logging functions where possible instead of the LOG* ones. Signed-off-by: Cédric Bosdonnat Acked-by: Wei Liu --- tools/libxl/libxl_colo_restore.c | 57 1

[Xen-devel] [PATCH v2 02/35] libxl.c: switch to LOG*D use

From: Cedric Bosdonnat Use LOG*D functions to output the domain ID in logs as much as possible. This will help consumer code sorting the logs by domain. libxl.c changes have been split into 3 commits to help review them and isolate more instances that could be problematic.

Re: [Xen-devel] megaraid_sas regression in linux-3.18 [and 1 more messages]

Sumit Saxena writes ("RE: megaraid_sas regression in linux-3.18"): > There was regression caused because of this commit. Please pick below > commit which fixes the regression- > > commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 > scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid

Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

On 02/12/16 14:21, Boris Ostrovsky wrote: > On 12/02/2016 09:06 AM, Andrew Cooper wrote: >> On 02/12/16 13:48, Roger Pau Monne wrote: >>> At the moment this flag is unconditionally set for PVHv2 domains. Note that >>> using this boot flag requires that the FADT table revision is at least 5 >>>

Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

On 12/02/2016 09:06 AM, Andrew Cooper wrote: > On 02/12/16 13:48, Roger Pau Monne wrote: >> At the moment this flag is unconditionally set for PVHv2 domains. Note that >> using this boot flag requires that the FADT table revision is at least 5 (or >> any >> later version), so bump the current

Re: [Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

On 02/12/16 13:48, Roger Pau Monne wrote: > At the moment this flag is unconditionally set for PVHv2 domains. Note that > using this boot flag requires that the FADT table revision is at least 5 (or > any > later version), so bump the current FADT version from 4 to 5 and add two new > fields that

Re: [Xen-devel] [PATCH v2 1/4] tools/libacpi: add _FADT_ to the FADT boot flags definitions

On Fri, Dec 02, 2016 at 01:53:44PM +, Andrew Cooper wrote: > On 02/12/16 13:48, Roger Pau Monne wrote: > > Signed-off-by: Roger Pau Monné > > --- > > Cc: Jan Beulich > > Cc: Andrew Cooper > > Cc: Ian Jackson

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

On 12/02/2016 04:45 AM, Ingo Molnar wrote: > * Boris Ostrovsky wrote: > >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote: >>> >>> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote: From: Matt Fleming The new Xen PVH entry point

Re: [Xen-devel] [PATCH v2 3/4] tools/libacpi: don't announce a 8042 controller in the FADT for PVHv2 guests

On 02/12/16 13:48, Roger Pau Monne wrote: > There's no such controler available for PVHv2 guests. > > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 2/4] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

On 02/12/16 13:48, Roger Pau Monne wrote: > diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h > index 5ddef8a..500f95e 100644 > --- a/tools/libacpi/acpi2_0.h > +++ b/tools/libacpi/acpi2_0.h > @@ -229,6 +229,8 @@ struct acpi_20_fadt { > */ > #define ACPI_FADT_LEGACY_DEVICES(1 <<

Re: [Xen-devel] [PATCH v2 1/4] tools/libacpi: add _FADT_ to the FADT boot flags definitions

On 02/12/16 13:48, Roger Pau Monne wrote: > Signed-off-by: Roger Pau Monné > --- > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Ian Jackson > Cc: Wei Liu > Cc:

[Xen-devel] [PATCH v2 2/4] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson

[Xen-devel] [PATCH v2 4/4] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

At the moment this flag is unconditionally set for PVHv2 domains. Note that using this boot flag requires that the FADT table revision is at least 5 (or any later version), so bump the current FADT version from 4 to 5 and add two new fields that will be unused. Reported-by: Jan Beulich

[Xen-devel] [PATCH v2 1/4] tools/libacpi: add _FADT_ to the FADT boot flags definitions

Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Wei Liu Cc: boris.ostrov...@oracle.com Cc: konrad.w...@oracle.com ---

[Xen-devel] [PATCH v2 3/4] tools/libacpi: don't announce a 8042 controller in the FADT for PVHv2 guests

There's no such controler available for PVHv2 guests. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Wei Liu Cc:

[Xen-devel] [PATCH v2 0/4] tools/libacpi: fix boot flags passed to PVHv2 guests

Hello, There are a couple of boot flags that should be passed to PVHv2 guests, that report the lack of VGA and CMOS RTC, and we shouldn't also pass the 8042 flag, because PVHv2 guests don't have access to such controller. The no CMOS RTC flags requires that the FADT table is bumped to version

Re: [Xen-devel] [PATCH v2] x86/cpuid: Add AVX512_4VNNIW and AVX512_4FMAPS support

On 22/11/16 10:57, Andrew Cooper wrote: > On 22/11/16 10:56, Wei Liu wrote: >> On Mon, Nov 21, 2016 at 02:01:14PM +0800, He Chen wrote: >>> Add two new AVX512 subfeatures support for guest. >>> >>> AVX512_4VNNIW: >>> Vector instructions for deep learning enhanced word variable precision. >>> >>>

[Xen-devel] Xen 4.8 branched, staging open for new patches

Hi all We just finished branching 4.8. The staging branch is now open for committing new patches. As always please be cautious about what patches are accepted into staging until 4.8 is released. For bug fixes please commit them to staging first then backport them to staging-4.8 (*). Thanks Wei.

Re: [Xen-devel] [PATCH 0/2] Open Xen 4.9-unstable, reenable debug

On Fri, Dec 02, Ian Jackson wrote: > I have pushed the first of these two patches to new-staging. It is > very like all previous such commits. The second, to reenable > hypervisor debug, I decided to get some review on. Please also bump the SONAMEs as it was done in commit

Re: [Xen-devel] megaraid_sas regression in linux-3.18

>-Original Message- >From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] >Sent: Friday, December 02, 2016 6:11 PM >To: Kashyap Desai; sta...@vger.kernel.org; Sumit Saxena; Tomas Henzl; Hannes >Reinecke; Ewan D.Milne; Martin K.Petersen; Sasha Levin >Cc: xen-de...@lists.xensource.com

  1   2   >