[Xen-devel] [xen-4.9-testing test] 116409: trouble: broken/fail/pass

flight 116409 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116409/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm broken

Re: [Xen-devel] [PATCH 02/16] SUPPORT.md: Add core functionality

>>> On 13.11.17 at 16:41, wrote: > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -16,6 +16,65 @@ for the definitions of the support status levels etc. > > # Feature Support > > +## Memory Management > + > +### Memory Ballooning > + > +Status: Supported Is this a

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

On 21/11/17 08:50, Jan Beulich wrote: On 20.11.17 at 19:28, wrote: >> On 20/11/17 17:14, Jan Beulich wrote: >> On 20.11.17 at 16:24, wrote: On 20/11/17 15:20, Jan Beulich wrote: On 20.11.17 at 15:14, wrote: >> On

Re: [Xen-devel] [PATCH 08/16] SUPPORT.md: Add x86-specific virtual hardware

>>> On 13.11.17 at 16:41, wrote: > +### x86/Nested PV > + > +Status, x86 HVM: Tech Preview > + > +This means running a Xen hypervisor inside an HVM domain, > +with support for PV L2 guests only > +(i.e., hardware virtualization extensions not provided > +to the

Re: [Xen-devel] [PATCH 12/16] SUPPORT.md: Add Security-releated features

>>> On 13.11.17 at 16:41, wrote: > With the exception of driver domains, which depend on PCI passthrough, > and will be introduced later. > > Signed-off-by: George Dunlap Shouldn't we also explicitly exclude tool stack disaggregation here,

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

>>> On 13.11.17 at 16:41, wrote: > +### ARM/SMMUv1 > + > +Status: Supported > + > +### ARM/SMMUv2 > + > +Status: Supported Do these belong here, when IOMMU isn't part of the corresponding x86 patch? Jan ___

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

>>> On 21.11.17 at 09:13, wrote: > On 21/11/17 08:50, Jan Beulich wrote: > On 20.11.17 at 19:28, wrote: >>> On 20/11/17 17:14, Jan Beulich wrote: >>> On 20.11.17 at 16:24, wrote: > So without my patch the RSDP table is loaded e.g.

Re: [Xen-devel] [PATCH 14/16] SUPPORT.md: Add statement on PCI passthrough

>>> On 13.11.17 at 16:41, wrote: > +### x86/PCI Device Passthrough > + > +Status: Supported, with caveats I think this wants to be ### PCI Device Passthrough Status, x86 HVM: Supported, with caveats Status, x86 PV: Supported, with caveats to (a) allow

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

flight 116372 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd broken test-amd64-amd64-xl-xsm

Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

>>> On 13.11.17 at 16:41, wrote: > +### Host ACPI (via Domain 0) > + > +Status, x86 PV: Supported > +Status, x86 PVH: Tech preview Are we this far already? Preview implies functional completeness, but I'm not sure about all ACPI related parts actually having

Re: [Xen-devel] [PATCH 06/16] SUPPORT.md: Add scalability features

>>> On 13.11.17 at 16:41, wrote: > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -195,6 +195,27 @@ on embedded platforms. > > Enables NUMA aware scheduling in Xen > > +## Scalability > + > +### 1GB/2MB super page support > + > +Status, x86 HVM/PVH: : Supported On

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

>>> On 13.11.17 at 16:41, wrote: > +### PV USB support for xl > + > +Status: Supported > + > +### PV 9pfs support for xl > + > +Status: Tech Preview Why are these two being called out, but xl support for other device types isn't? > +### QEMU backend hotplugging

Re: [Xen-devel] [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem

>>> On 13.11.17 at 16:41, wrote: > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -152,6 +152,35 @@ Output of information in machine-parseable JSON format > > Status: Supported, Security support external > > +## Debugging, analysis, and crash post-mortem > + > +###

Re: [Xen-devel] [PATCH 11/16] SUPPORT.md: Add 'easy' HA / FT features

>>> On 13.11.17 at 16:41, wrote: > +### x86/vMCE > + > +Status: Supported > + > +Forward Machine Check Exceptions to Appropriate guests Acked-by: Jan Beulich perhaps with the A converted to lower case. Jan

[Xen-devel] [seabios test] 116373: regressions - trouble: broken/fail/pass

flight 116373 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-ws16-amd64 17

Re: [Xen-devel] [PATCH 13/16] SUPPORT.md: Add secondary memory management features

>>> On 13.11.17 at 16:41, wrote: > Signed-off-by: George Dunlap Wouldn't PoD belong here too? With that added as supported on x86 HVM Acked-by: Jan Beulich Jan ___ Xen-devel

Re: [Xen-devel] [PATCH 2/2 v2] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform

Hi, On Thursday 16 November 2017 03:26 PM, George Dunlap wrote: On Nov 15, 2017, at 9:20 PM, Konrad Rzeszutek Wilk wrote: On Thu, Nov 09, 2017 at 03:49:24PM +0530, Bhupinder Thakur wrote: The console was not working on HP Moonshot (HPE Proliant Aarch64) because

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

> -Original Message- [snip] > > +### PV keyboard (frontend) > > + > > +Status, Linux (xen-kbdfront): Supported > > +Status, Windows: Supported > > + > > +Guest-side driver capable of speaking the Xen PV keyboard protocol > > Are these three active/usable in guests regardless of

Re: [Xen-devel] [PATCH 16/16] SUPPORT.md: Add limits RFC

>>> On 13.11.17 at 16:41, wrote: > +### Virtual CPUs > + > +Limit, x86 PV: 8192 > +Limit-security, x86 PV: 32 > +Limit, x86 HVM: 128 > +Limit-security, x86 HVM: 32 Personally I consider the "Limit-security" numbers too low here, but I have no proof that

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

On 11/21/2017 08:29 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> +### PV USB support for xl >> + >> +Status: Supported >> + >> +### PV 9pfs support for xl >> + >> +Status: Tech Preview > > Why are these two being called out, but xl support for

[Xen-devel] [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

The "special pages" for PVH guests include the frames for console and Xenstore ring buffers. Those have to be marked as "Reserved" in the guest's E820 map, as otherwise conflicts might arise later e.g. when hotplugging memory into the guest. Signed-off-by: Juergen Gross --- This

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

On 21/11/17 11:42, Andrew Cooper wrote: > On 21/11/17 07:44, Jan Beulich wrote: > On 20.11.17 at 17:59, wrote: >>> On 11/20/2017 11:43 AM, Jan Beulich wrote: >>> On 20.11.17 at 17:28, wrote: > On 11/20/2017 11:26 AM, Jan Beulich

Re: [Xen-devel] [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

>>> On 21.11.17 at 12:06, wrote: > The "special pages" for PVH guests include the frames for console and > Xenstore ring buffers. Those have to be marked as "Reserved" in the > guest's E820 map, as otherwise conflicts might arise later e.g. when > hotplugging memory into the

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

On 21/11/17 09:46, Jan Beulich wrote: On 21.11.17 at 09:13, wrote: >> On 21/11/17 08:50, Jan Beulich wrote: >> On 20.11.17 at 19:28, wrote: On 20/11/17 17:14, Jan Beulich wrote: On 20.11.17 at 16:24, wrote: >> So

Re: [Xen-devel] [PATCH for-4.10] tools/libxc: Fix restoration of PV MSRs after migrate

Hi, On 11/16/2017 09:13 PM, Andrew Cooper wrote: There are two bugs in process_vcpu_msrs() which clearly demonstrate that I didn't test this bit of Migration v2 very well when writing it... vcpu->msrsz is always expected to be a multiple of xen_domctl_vcpu_msr_t records in a spec-compliant

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

Hi, On 11/16/2017 10:45 PM, Andrew Cooper wrote: Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a bug whereby it corrupts the HVM context stream if some, but fewer than the maximum number of MSRs are written. _hvm_init_entry() creates an hvm_save_descriptor with

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

On 11/21/2017 08:11 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> +### ARM/SMMUv1 >> + >> +Status: Supported >> + >> +### ARM/SMMUv2 >> + >> +Status: Supported > > Do these belong here, when IOMMU isn't part of the corresponding > x86 patch? Since

[Xen-devel] [xen-4.5-testing baseline-only test] 72472: regressions - FAIL

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

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

flight 116377 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116377/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumprun-amd64 broken test-amd64-amd64-libvirt

Re: [Xen-devel] [PATCH 02/16] SUPPORT.md: Add core functionality

On 11/21/2017 08:03 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> --- a/SUPPORT.md >> +++ b/SUPPORT.md >> @@ -16,6 +16,65 @@ for the definitions of the support status levels etc. >> >> # Feature Support >> >> +## Memory Management >> + >> +### Memory

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

On 21/11/17 07:44, Jan Beulich wrote: On 20.11.17 at 17:59, wrote: >> On 11/20/2017 11:43 AM, Jan Beulich wrote: >> On 20.11.17 at 17:28, wrote: On 11/20/2017 11:26 AM, Jan Beulich wrote: On 20.11.17 at 17:14,

Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

On 11/21/2017 08:09 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> +### x86/PVH guest >> + >> +Status: Supported >> + >> +PVH is a next-generation paravirtualized mode >> +designed to take advantage of hardware virtualization support when possible. >>

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

On 21/11/17 09:37, Juergen Gross wrote: > On 21/11/17 09:46, Jan Beulich wrote: > On 21.11.17 at 09:13, wrote: >>> On 21/11/17 08:50, Jan Beulich wrote: >>> On 20.11.17 at 19:28, wrote: > On 20/11/17 17:14, Jan Beulich wrote: > On 20.11.17 at

Re: [Xen-devel] [PATCH 02/16] SUPPORT.md: Add core functionality

>>> On 21.11.17 at 11:36, wrote: > On 11/21/2017 08:03 AM, Jan Beulich wrote: > On 13.11.17 at 16:41, wrote: >>> --- a/SUPPORT.md >>> +++ b/SUPPORT.md >>> @@ -16,6 +16,65 @@ for the definitions of the support status levels etc. >>> >>> #

Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

>>> On 21.11.17 at 11:42, wrote: > On 11/21/2017 08:09 AM, Jan Beulich wrote: > On 13.11.17 at 16:41, wrote: >>> +### x86/PVH guest >>> + >>> +Status: Supported >>> + >>> +PVH is a next-generation paravirtualized mode >>> +designed to

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

>>> On 21.11.17 at 11:45, wrote: > On 11/21/2017 08:11 AM, Jan Beulich wrote: > On 13.11.17 at 16:41, wrote: >>> +### ARM/SMMUv1 >>> + >>> +Status: Supported >>> + >>> +### ARM/SMMUv2 >>> + >>> +Status: Supported >> >> Do these

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

>>> On 21.11.17 at 11:56, wrote: > On 11/21/2017 08:29 AM, Jan Beulich wrote: > On 13.11.17 at 16:41, wrote: >>> +### PV USB support for xl >>> + >>> +Status: Supported >>> + >>> +### PV 9pfs support for xl >>> + >>> +Status: Tech

Re: [Xen-devel] [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

On 21/11/17 12:27, Jan Beulich wrote: On 21.11.17 at 12:06, wrote: >> The "special pages" for PVH guests include the frames for console and >> Xenstore ring buffers. Those have to be marked as "Reserved" in the >> guest's E820 map, as otherwise conflicts might arise later

Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

On Nov 21, 2017, at 11:35 AM, Jan Beulich > wrote: On 21.11.17 at 11:42, > wrote: On 11/21/2017 08:09 AM, Jan Beulich wrote: On 13.11.17 at 16:41,

Re: [Xen-devel] [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

>>> On 21.11.17 at 12:48, wrote: > On 21/11/17 12:27, Jan Beulich wrote: > On 21.11.17 at 12:06, wrote: >>> The "special pages" for PVH guests include the frames for console and >>> Xenstore ring buffers. Those have to be marked as "Reserved" in the >>>

[Xen-devel] [PATCH] mini-os: add config item for printing via hypervisor

Today Mini-OS will print all console output via the hypervisor, too. Make this behavior configurable instead and default it to "off". Signed-off-by: Juergen Gross --- Config.mk | 2 ++ arch/x86/testbuild/all-no | 1 + arch/x86/testbuild/all-yes| 1 +

Re: [Xen-devel] [PATCH] VMX: sync CPU state upon vCPU destruction

On 09/11/17 14:49, Jan Beulich wrote: > See the code comment being added for why we need this. > > Reported-by: Igor Druzhinin > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -479,7 +479,13

Re: [Xen-devel] [PATCH v2 2/5] xen: Provide XEN_DMOP_add_to_physmap

>>> On 23.10.17 at 11:05, wrote: First of all, instead of xen: please consider using something more specific, like x86/hvm:. > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -368,6 +368,22 @@ struct xen_dm_op_remote_shutdown { >

[Xen-devel] [libvirt test] 116391: trouble: broken/pass

flight 116391 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116391/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair broken

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 11/21/2017 04:42 PM, Dario Faggioli wrote: > On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: > On 21.11.17 at 15:07, wrote: >>> >> The question here is: In what other cases do we expect an RCU >> callback to possibly touch guest state? I think the common

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

On 11/21/2017 08:29 AM, Jan Beulich wrote: >> +### QEMU backend hotplugging for xl >> + >> +Status: Supported > > Wouldn't this more appropriately be > > ### QEMU backend hotplugging > > Status, xl: Supported You mean, for this whole section (i.e., everything here that says 'for xl')?

Re: [Xen-devel] [PATCH v2 1/5] xen/mm: Make xenmem_add_to_physmap global

>>> On 23.10.17 at 11:05, wrote: > Make it global in preparation to be called by a new dmop. > > Signed-off-by: Ross Lagerwall > > --- > Reviewed-by: Paul Durrant Misplaced tag. I'd prefer if the function was

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 11/21/2017 01:22 PM, Jan Beulich wrote: On 09.11.17 at 15:49, wrote: >> See the code comment being added for why we need this. >> >> Reported-by: Igor Druzhinin >> Signed-off-by: Jan Beulich > > I realize we aren't

Re: [Xen-devel] [PATCH 06/16] SUPPORT.md: Add scalability features

On 11/16/2017 03:19 PM, Julien Grall wrote: > Hi George, > > On 13/11/17 15:41, George Dunlap wrote: >> Superpage support and PVHVM. >> >> Signed-off-by: George Dunlap >> --- >> CC: Ian Jackson >> CC: Wei Liu >> CC: Andrew

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

Hi George, On 11/21/2017 10:45 AM, George Dunlap wrote: On 11/21/2017 08:11 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: +### ARM/SMMUv1 + +Status: Supported + +### ARM/SMMUv2 + +Status: Supported Do these belong here, when IOMMU isn't part of the

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: > > > > On 21.11.17 at 15:07, wrote: > > > The question here is: In what other cases do we expect an RCU > callback to possibly touch guest state? I think the common use is > to merely free some memory in a delayed

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: > > > > On 21.11.17 at 15:07, wrote: > > > > On 21/11/17 13:22, Jan Beulich wrote: > > > > > > On 09.11.17 at 15:49, wrote: > > > > > > > > See the code comment being added for why we need this.

[Xen-devel] [xen-4.6-testing baseline-only test] 72473: regressions - FAIL

This run is configured for baseline tests only. flight 72473 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72473/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-121

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

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

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

>>> On 21.11.17 at 18:00, wrote: > On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: >> > > > On 21.11.17 at 15:07, wrote: >> > >> > On 21/11/17 13:22, Jan Beulich wrote: >> > > > > > On 09.11.17 at 15:49, wrote: >> >

Re: [Xen-devel] [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86

On 11/21/2017 11:41 AM, Jan Beulich wrote: On 21.11.17 at 11:56, wrote: >> On 11/21/2017 08:29 AM, Jan Beulich wrote: >> On 13.11.17 at 16:41, wrote: +### PV USB support for xl + +Status: Supported + +###

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 21/11/17 15:29, Jan Beulich wrote: On 21.11.17 at 15:07, wrote: >> On 21/11/17 13:22, Jan Beulich wrote: >> On 09.11.17 at 15:49, wrote: See the code comment being added for why we need this. Reported-by: Igor Druzhinin

Re: [Xen-devel] [PATCH 06/16] SUPPORT.md: Add scalability features

Hi George, On 11/21/2017 04:43 PM, George Dunlap wrote: On 11/16/2017 03:19 PM, Julien Grall wrote: On 13/11/17 15:41, George Dunlap wrote: Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Andrew Cooper

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

>>> On 21.11.17 at 13:39, wrote: > What about something like this? > > ### IOMMU > > Status, AMD IOMMU: Supported > Status, Intel VT-d: Supported > Status, ARM SMMUv1: Supported > Status, ARM SMMUv2: Supported Fine with me, as it makes things explicit.

Re: [Xen-devel] Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

On 21/11/17 13:26, Jan Beulich wrote: On 06.11.17 at 16:04, wrote: >> On 11/06/2017 11:59 AM, Jan Beulich wrote: >> On 16.10.17 at 14:42, wrote: >>> On 16.10.17 at 14:37, wrote: > On 16/10/17 13:32, Jan Beulich wrote: >>

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

>>> On 21.11.17 at 15:07, wrote: > On 21/11/17 13:22, Jan Beulich wrote: > On 09.11.17 at 15:49, wrote: >>> See the code comment being added for why we need this. >>> >>> Reported-by: Igor Druzhinin >>> Signed-off-by:

Re: [Xen-devel] [PATCH 04/16] SUPPORT.md: Add core ARM features

On Nov 21, 2017, at 11:37 AM, Jan Beulich > wrote: On 21.11.17 at 11:45, > wrote: On 11/21/2017 08:11 AM, Jan Beulich wrote: On 13.11.17 at 16:41,

[Xen-devel] [PATCH v6 00/16] xen: common: rbtree: ported updates from Linux tree

Hi All, The patch imports the changes and updates of the rbtree implementaiton from Linux tree. But since, the only current implementation is with tmem.c, which am not much aware off much and therefore, was unable to test the changes thoroughly. Having said that, I do have plans of adding futher

[Xen-devel] [PATCH v6 02/16 RESEND] rbtree: empty nodes have no color

From: Michel Lespinasse Empty nodes have no color. We can make use of this property to simplify the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE macros. Also, we can get rid of the rb_init_node function which had been introduced by commit 88d19cf37952 ("timers: Add

[Xen-devel] [PATCH v6 01/16] rbtree: remove redundant if()-condition in rb_erase()

From: Wolfram Strepp Furthermore, notice that the initial checks: if (!node->rb_left) child = node->rb_right; else if (!node->rb_right) child = node->rb_left; else { ...

[Xen-devel] Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

>>> On 06.11.17 at 16:04, wrote: > On 11/06/2017 11:59 AM, Jan Beulich wrote: > On 16.10.17 at 14:42, wrote: >> On 16.10.17 at 14:37, wrote: On 16/10/17 13:32, Jan Beulich wrote: > Since the emulator acts on the live hardware

[Xen-devel] [PATCH v6 08/16 RESEND] rbtree: optimize case selection logic in __rb_erase_color()

From: Michel Lespinasse In __rb_erase_color(), we have to select one of 3 cases depending on the color on the 'other' node children. If both children are black, we flip a few node colors and iterate. Otherwise, we do either one or two tree rotations, depending on the color

[Xen-devel] [PATCH v6 10/16 RESEND] rbtree: coding style adjustments

From: Michel Lespinasse Set comment and indentation style to be consistent with linux coding style and the rest of the file, as suggested by Peter Zijlstra Signed-off-by: Michel Lespinasse Cc: Andrea Arcangeli Acked-by: David

[Xen-devel] [PATCH v6 11/16 RESEND] rbtree: optimize fetching of sibling node

From: Michel Lespinasse When looking to fetch a node's sibling, we went through a sequence of: - check if node is the parent's left child - if it is, then fetch the parent's right child This can be replaced with: - fetch the parent's right child as an assumed sibling - check

[Xen-devel] [PATCH v6 12/16 RESEND] rbtree: add __rb_change_child() helper function

From: Michel Lespinasse Add __rb_change_child() as an inline helper function to replace code that would otherwise be duplicated 4 times in the source. No changes to binary size or speed. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel

[Xen-devel] [PATCH v6 06/16 RESEND] rbtree: low level optimizations in rb_insert_color()

From: Michel Lespinasse - Use the newly introduced rb_set_parent_color() function to flip the color of nodes whose parent is already known. - Optimize rb_parent() when the node is known to be red - there is no need to mask out the color in that case. - Flipping gparent's

[Xen-devel] [PATCH v6 14/16] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

From: Michel Lespinasse An interesting observation for rb_erase() is that when a node has exactly one child, the node must be black and the child must be red. An interesting consequence is that removing such a node can be done by simply replacing it with its child and making

[Xen-devel] [PATCH v6 15/16 RESEND] rbtree: low level optimizations in rb_erase()

From: Michel Lespinasse Various minor optimizations in rb_erase(): - Avoid multiple loading of node->__rb_parent_color when computing parent and color information (possibly not in close sequence, as there might be further branches in the algorithm) - In the 1-child subcase

[Xen-devel] [PATCH v6 09/16 RESEND] rbtree: low level optimizations in __rb_erase_color()

From: Michel Lespinasse In __rb_erase_color(), we often already have pointers to the nodes being rotated and/or know what their colors must be, so we can generate more efficient code than the generic __rb_rotate_left() and __rb_rotate_right() functions. Also when the current

[Xen-devel] [PATCH v6 07/16 RESEND] rbtree: adjust node color in __rb_erase_color() only when necessary

From: Michel Lespinasse In __rb_erase_color(), we were always setting a node to black after exiting the main loop. And in one case, after fixing up the tree to satisfy all rbtree invariants, we were setting the current node to root just to guarantee a loop exit, at which

[Xen-devel] [PATCH v6 04/16 RESEND] rbtree: break out of rb_insert_color loop after tree rotation

From: Michel Lespinasse It is a well known property of rbtrees that insertion never requires more than two tree rotations. In our implementation, after one loop iteration identified one or two necessary tree rotations, we would iterate and look for more. However at that

[Xen-devel] [PATCH v6 03/16 RESEND] rbtree: move some implementation details from rbtree.h to rbtree.c

From: Michel Lespinasse rbtree users must use the documented APIs to manipulate the tree structure. Low-level helpers to manipulate node colors and parenthood are not part of that API, so move them to lib/rbtree.c Signed-off-by: Michel Lespinasse Cc:

[Xen-devel] [PATCH v6 16/16 RESEND] rbtree: fix typo in comment of rb_insert_color

From: Wei Yang In case 1, it passes down the BLACK color from G to p and u, and maintains the color of n. By doing so, it maintains the black height of the sub-tree. While in the comment, it marks the color of n to BLACK. This is a typo and not consistents with the

[Xen-devel] [PATCH v6 05/16 RESEND] rbtree: adjust root color in rb_insert_color() only when necessary

From: Michel Lespinasse The root node of an rbtree must always be black. However, rb_insert_color() only needs to maintain this invariant when it has been broken - that is, when it exits the loop due to the current (red) node being the root. In all other cases (exiting after

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

Hi all, Quick reminder, the call will be tomorrow (Wednesday 22nd) at 5pm GMT. The details to join the call are: Call+44 1223 406065 (Local dial in) and enter the access code below followed by # key. Participant code: 4915191 Mobile Auto Dial: VoIP:

Re: [Xen-devel] [PATCH 03/16] SUPPORT.md: Add some x86 features

>>> On 21.11.17 at 13:24, wrote: >> On Nov 21, 2017, at 11:35 AM, Jan Beulich >> Much depends on whether you think "guest" == "DomU". To me >> Dom0 is a guest, too. > > That’s not how I’ve ever understood those terms. > > A guest at a hotel is someone who is served,

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

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

[Xen-devel] [xen-4.9-testing test] 116378: regressions - trouble: broken/fail/pass

flight 116378 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116378/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64broken test-amd64-amd64-livepatch

Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

On 21/11/17 13:22, Jan Beulich wrote: On 09.11.17 at 15:49, wrote: >> See the code comment being added for why we need this. >> >> Reported-by: Igor Druzhinin >> Signed-off-by: Jan Beulich > > I realize we aren't settled yet

[Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction

>>> On 09.11.17 at 15:49, wrote: > See the code comment being added for why we need this. > > Reported-by: Igor Druzhinin > Signed-off-by: Jan Beulich I realize we aren't settled yet on where to put the sync call. The discussion

[Xen-devel] [PATCH v6 13/16 RESEND] rbtree: place easiest case first in rb_erase()

From: Michel Lespinasse In rb_erase, move the easy case (node to erase has no more than 1 child) first. I feel the code reads easier that way. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel Cc: Peter Zijlstra

Re: [Xen-devel] [PATCH 06/16] SUPPORT.md: Add scalability features

On 11/21/2017 05:31 PM, Julien Grall wrote: > Hi George, > > On 11/21/2017 04:43 PM, George Dunlap wrote: >> On 11/16/2017 03:19 PM, Julien Grall wrote: >>> On 13/11/17 15:41, George Dunlap wrote: Signed-off-by: George Dunlap --- CC: Ian Jackson

Re: [Xen-devel] [PATCH 08/16] SUPPORT.md: Add x86-specific virtual hardware

On 11/21/2017 08:39 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> +### x86/Nested PV >> + >> +Status, x86 HVM: Tech Preview >> + >> +This means running a Xen hypervisor inside an HVM domain, >> +with support for PV L2 guests only >> +(i.e., hardware

Re: [Xen-devel] [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem

George Dunlap writes ("Re: [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem"): > gdbsx security support: Someone may want to debug an untrusted guest, > so I think we should say 'yes' here. I think running gdb on an potentially hostile program is foolish. > I don't have a

Re: [Xen-devel] [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem

On 21/11/17 19:05, Ian Jackson wrote: > George Dunlap writes ("Re: [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, > crash post-portem"): >> gdbsx security support: Someone may want to debug an untrusted guest, >> so I think we should say 'yes' here. > I think running gdb on an potentially

Re: [Xen-devel] [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem

On 11/21/2017 08:48 AM, Jan Beulich wrote: On 13.11.17 at 16:41, wrote: >> --- a/SUPPORT.md >> +++ b/SUPPORT.md >> @@ -152,6 +152,35 @@ Output of information in machine-parseable JSON format >> >> Status: Supported, Security support external >> >> +##

Re: [Xen-devel] [PATCH 13/16] SUPPORT.md: Add secondary memory management features

On 13/11/17 15:41, George Dunlap wrote: > Signed-off-by: George Dunlap > --- > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Stefano Stabellini

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

flight 116388 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116388/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken

[Xen-devel] [linux-3.18 test] 116394: trouble: broken/fail/pass

flight 116394 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/116394/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw broken

Re: [Xen-devel] [PATCH] mini-os: add config item for printing via hypervisor

Hello, Juergen Gross, on mar. 21 nov. 2017 16:15:09 +0100, wrote: > Today Mini-OS will print all console output via the hypervisor, too. > > Make this behavior configurable instead and default it to "off". > -/* Copies all print output to the Xen emergency console apart > - of standard dom0

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm testid xen-boot Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree:

[Xen-devel] Xen PV seems to be broken on Linus' tree

I'm doing: /usr/bin/qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -net none -nographic -kernel xen-4.8.2 -initrd './arch/x86/boot/bzImage' -m 2G -smp 2 -append console=com1 With Linus' commit c8a0739b185d11d6e2ca7ad9f5835841d1cfc765 and the attached config. It dies with a bunch of

[Xen-devel] [seabios test] 116396: regressions - trouble: broken/fail/pass

flight 116396 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116396/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64broken test-amd64-i386-qemuu-rhel6hvm-amd

[Xen-devel] [distros-debian-snapshot test] 72475: tolerable FAIL

flight 72475 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72475/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 72445

[Xen-devel] [linux-4.9 test] 116395: trouble: broken/fail/pass

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

  1   2   >