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
test-amd64-i386-x
flight 116398 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116398/
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
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the
flight 116399 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt broken
test-amd64-i386-xl-qemut-stubdom-debia
On Tue, Nov 21, 2017 at 8:11 PM, Andy Lutomirski wrote:
> On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski wrote:
>> 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 co
On Tue, Nov 21, 2017 at 7:33 PM, Andy Lutomirski wrote:
> 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 c8a0739b185d11d6e2ca7ad9f58358
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 sensible
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: lin
On 11/20/2017 7:25 AM, Julien Grall wrote:
> Hi Sameer,
>
> On 19/11/17 07:45, Goel, Sameer wrote:
>> On 10/12/2017 10:36 AM, Julien Grall wrote:
+
+typedef paddr_t phys_addr_t;
+typedef paddr_t dma_addr_t;
+
+/* Alias to Xen device tree helpers */
+#define device_n
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
test-amd64-amd64-amd
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
test-amd64-i386-xl-qem
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
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 ha
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
test-amd64-amd64-xl-xs
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
test-amd64-amd64-xl-qemut-debianhvm-amd64
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
> CC: Konrad Wilk
> CC: Tim Deegan
> CC: Tamas K Lengyel
> ---
> SUPPORT.md | 31 +++
> 1
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 host
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 str
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
>>
>> +## Debugging, analysis, and crash p
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 virtualization extensions not
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
CC: Wei Liu
CC: Andrew C
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')?
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
CC: Jan Beulich
CC: Stefano Stabellini
CC: Konrad Wilk
CC: Tim Deega
>>> 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:
>> > > >
>> > > > See the code comment being added for why we need this.
>> >
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
test-amd64-i386-xl-qemuu-debianhvm-amd6
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
+
+### PV 9pfs support for xl
+
+Status: Tech P
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.
> > > >
> > > > Reported-by: Igor Druzhinin
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 corresponding
x86 patch?
S
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 use is
>> to merely free some
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
test-amd64-i386-libvirt-p
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 Cooper
>> CC: Jan Beulich
>> CC: Stefano Stabellini
>> CC: Konrad Wil
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 fashion.
>
> > Those choice
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 xtf/test-hvm32-
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 @@ static void vmx_vcpu_destroy(struct vcpu
>
>>> 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 {
> /* (O
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 settled yet on where to put the sync call. The
> discussion appears to h
>>> 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 made non-static in the patch which
needs it so, but anyway
Acked-by: Jan Beulich
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
Signed-off-by: Jan Beulich
>>>
>>> I realiz
>>> 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: Jan Beulich
>>
>> I realize we aren't settled yet on where to put the sy
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
Cc: Andrea Arcangeli
Cc: David Woodhouse
Signed-off-by: Andrew Morton
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 code.
This patch fixs this
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
Cc: Peter Zijlstra
Cc: Andrea Arcangeli
Cc: D
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 color to red requires
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 the child black,
whic
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 of case 1, copy the
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 of the 'other' child
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 Woodhouse
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Daniel Santos
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 that node is NOT the
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 tree rotations, or
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 node is red or when
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 point the root would be
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 point the node's parent
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: Andrea Arcangeli
Acked-by: David Woodhouse
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 rb_init_node() to allo
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 c
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
{
...
}
guar
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 +
arch/x86/testbui
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: voip://+441223406065;4915
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 on where to put the sync call. The
> discussion appears to have s
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 1
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:
>> Since the emulator acts on the live hardware registers
>>> 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 registers, we need to
> prevent the compiler from
>>> 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 appears to have stalled, though. Just to recap,
alternatives to t
>>> 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.
Jan
___
>>> 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, and who does not have (legal
>>> 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
>>> guest's E820 map, as otherwise conflict
On Nov 21, 2017, at 11:37 AM, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 21.11.17 at 11:45,
mailto:george.dun...@citrix.com>> wrote:
On 11/21/2017 08:11 AM, Jan Beulich wrote:
On 13.11.17 at 16:41,
mailto:george.dun...@citrix.com>> wrote:
+### ARM/SMMUv1
+
+Status: Supported
+
+###
Jan Beulich writes ("Re: [PATCH 03/16] SUPPORT.md: Add some x86 features"):
> Much depends on whether you think "guest" == "DomU". To me
> Dom0 is a guest, too.
Not to me. I'm with George. (As far as I can make out his message,
which I think was sent with HTML-style quoting which some Citrix thi
On Nov 21, 2017, at 11:35 AM, Jan Beulich
mailto:jbeul...@suse.com>> wrote:
On 21.11.17 at 11:42,
mailto:george.dun...@citrix.com>> wrote:
On 11/21/2017 08:09 AM, Jan Beulich wrote:
On 13.11.17 at 16:41,
mailto:george.dun...@citrix.com>> wrote:
+### x86/PVH guest
+
+Status: Supported
+
+P
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
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 e.g. when
>> hotplug
>>> 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 Preview
>>
>> Why are these two being called out, but
>>> 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 belong here, when IOMMU isn't part of the corresponding
>>> 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 take advantage of hardware virtualization support whe
>>> 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.
>>>
>>> # Feature Support
>>>
>>> +## Memory Management
>>>
>>> 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 guest.
Afaict this di
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 wrote:
> On 20.11.17 at 17:14, wrote:
>>> W
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 is a bugfix for P
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 other device
> types isn't?
D
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 there was recently a time
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 16:24, wrote:
>>> So without
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.
>> +During development this was
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, wrote:
>> What could cause grub2 to fail to find space for
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 len
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 stre
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 Ballooning
>> +
>> +Stat
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
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 guest-savere
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 without my patch the RSDP table is loaded e.g. at about
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
>>> 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 higher numbers will work _i
> -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 whe
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
the UART registers we
>>> 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 later extending for ARM and (b
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
>>> 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 mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> 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,
with reference to XSA-77?
Jan
__
>>> 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 mailing list
Xen-devel@li
>>> 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
> +
> +### gdbsx
> +
> +Status, x86:
>>> 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. at about 6.5MB when
> I'm using grub2 (the loaded
1 - 100 of 107 matches
Mail list logo
