flight 167633 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167633/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167623
test-armhf-armhf-libvirt 16 sav
Hi Stefano,
On 08/01/2022 00:49, Stefano Stabellini wrote:
From: Luca Miccio
Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabel
Hi Stefano,
On 08/01/2022 00:49, Stefano Stabellini wrote:
From: Luca Miccio
If the function is called with late_init set then also notify the domain
using the xenstore event channel.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: w...@xen.org
CC: Anthony PERARD
CC: Juerg
Hi,
On 08/01/2022 00:49, Stefano Stabellini wrote:
From: Luca Miccio
Add a late_init argument to xs_introduce_domain to handle dom0less
guests whose xenstore interfaces are initialized after boot.
This patch mechanically adds the new parameter; it doesn't change
behaviors.
Signed-off-by: Luc
Hi,
On 08/01/2022 00:49, Stefano Stabellini wrote:
From: Luca Miccio
Introduce a new feature flag to signal that xenstore will not be
immediately available at boot time. Instead, xenstore will become
available later, and a notification of xenstore readiness will be
signalled to the guest using
flight 167631 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167631/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167624
test-amd64-amd64-qemuu-nested-amd 20
On Fri, Jan 07, 2022 at 04:49:11PM -0800, Stefano Stabellini wrote:
> From: Luca Miccio
>
> If the function is called with late_init set then also notify the domain
> using the xenstore event channel.
>
> Signed-off-by: Luca Miccio
> Signed-off-by: Stefano Stabellini
> CC: w...@xen.org
> CC: A
On Fri, Jan 07, 2022 at 04:49:08PM -0800, Stefano Stabellini wrote:
> From: Luca Miccio
>
> Add a late_init argument to xs_introduce_domain to handle dom0less
> guests whose xenstore interfaces are initialized after boot.
>
> This patch mechanically adds the new parameter; it doesn't change
> be
flight 167630 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167630/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-qcow2 13 guest-startfail in 167622 pass in 167630
test-amd64-amd64-dom0pvh-xl-inte
From: Luca Miccio
XENFEAT_xenstore_late_init requires xenstore to be initialized later,
after receiving an event channel notification on the xenstore event
channel (which is available since boot).
This patch adds support for delaying the Xenstore initialization as
required when XENFEAT_xenstore_
From: Luca Miccio
Add the new XENFEAT_xenstore_late_init flag to the features header file.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
---
include/xen/interface/features.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/xen/interface/features.h b/include/xen/
Hi all,
This small patch series for Linux implements support for the new feature
flag XENFEAT_xenstore_late_init. See "[XEN PATCH 0/7] dom0less PV
drivers" for the Xen side.
With this small patch series applied, it is possible to use PV drivers
in Linux when Linux is booted as dom0less kernel.
C
From: Luca Miccio
Add an example application that can be run in dom0 to complete the
dom0less domains initialization so that they can get access to xenstore
and use PV drivers.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
---
From: Stefano Stabellini
Introduce a new "xen,enhanced" dom0less property to enable/disable PV
driver interfaces for dom0less guests. Currently only "enabled" and
"disabled" are supported property values (and empty). Leave the option
open to implement further possible values in the future (e.g.
"
From: Luca Miccio
The xenstore event channel will be allocated for dom0less domains. It is
necessary to have access to the evtchn_alloc_unbound function to do
that.
Factor out the part that actually allocates the event channel from
evtchn_alloc_unbound and introduce this new function as
_evtchn_
From: Luca Miccio
If the function is called with late_init set then also notify the domain
using the xenstore event channel.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: w...@xen.org
CC: Anthony PERARD
CC: Juergen Gross
CC: jul...@xen.org
---
tools/xenstore/xenstored_dom
From: Luca Miccio
If "xen,enhanced" is enabled, then add to dom0less domains:
- the hypervisor node in device tree
- the xenstore event channel
The xenstore event channel is also used for the first notification to
let the guest know that xenstore has become available.
Signed-off-by: Luca Micci
From: Luca Miccio
Add a late_init argument to xs_introduce_domain to handle dom0less
guests whose xenstore interfaces are initialized after boot.
This patch mechanically adds the new parameter; it doesn't change
behaviors.
Signed-off-by: Luca Miccio
Signed-off-by: Stefano Stabellini
CC: w...@
From: Luca Miccio
Introduce a new feature flag to signal that xenstore will not be
immediately available at boot time. Instead, xenstore will become
available later, and a notification of xenstore readiness will be
signalled to the guest using the xenstore event channel.
Signed-off-by: Luca Micc
Hi all,
Currently dom0less guests cannot use PV drivers because they don't have
access to xenstore. Also, the hypervisor node in device tree is missing
so they don't detect that they are running on Xen (thus, they don't try
to enable PV interfaces.)
This patch series enables dom0less guests (on A
flight 167629 xen-4.14-testing real [real]
flight 167632 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167629/
http://logs.test-lab.xenproject.org/osstest/logs/167632/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 167628 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167628/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 167416
test-amd64-amd64-qemuu-nested-am
On Wed, Jan 5, 2022 at 10:33 PM Roger Pau Monné wrote:
>
> On Wed, Jan 05, 2022 at 12:05:39AM +0800, G.R. wrote:
> > > > > > But seems like this patch is not stable enough yet and has its own
> > > > > > issue -- memory is not properly released?
> > > > >
> > > > > I know. I've been working on imp
On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
> On 06.01.2022 16:08, James Dingwall wrote:
> >>> On Wed, Jul 21, 2021 at 12:59:11PM +0200, Jan Beulich wrote:
> >>>
> On 21.07.2021 11:29, James Dingwal
On 07/01/2022 13:45, Andrew Cooper wrote:
printk("Callback via PCI dev %u INTx %u%s\n",
PCI 00:%02x.0 ?
Is this correct? If I remember right, the INTx lines are associated with
a PCI device, with the function then reporting which line it uses.
So Xen neither knows (nor cares) what
On Tue, Dec 14, 2021 at 02:52:43PM +0100, Jan Beulich wrote:
> On 14.12.2021 14:34, Jason Andryuk wrote:
> > On Tue, Dec 14, 2021 at 2:50 AM Jan Beulich wrote:
> >>
> >> Attempting to wait when the backend hasn't been created yet can't work:
> >> the function will complain "Backend ... does not ex
On 20.12.2021 06:21, Penny Zheng wrote:
> From: Stefano Stabellini
>
> This commit introduces a new arm-specific flag CDF_directmap to specify
> that a domain should have its memory direct-map(guest physical address
> == physical address) at domain creation.
>
> Also, add a directmap flag under
On 20.12.2021 06:21, Penny Zheng wrote:
> From: Stefano Stabellini
>
> We are passing an internal-only boolean flag at domain creation to
> specify whether we want the domain to be privileged (i.e. dom0) or
> not. Another flag will be introduced later in this series.
>
> This commit extends orig
On 07/01/2022 13:45, Andrew Cooper wrote:
> I realise this is all a complete mess, but is via_asserted correct for
> HVMIRQ_callback_vector? It's mismatched between the two, and the best
> metric that exists is "is pending in IRR".
Urgh. HVMIRQ_callback_vector is the one that is utterly broken,
On 07/01/2022 12:55, David Vrabel wrote:
> @@ -630,9 +634,46 @@ static void irq_dump(struct domain *d)
> hvm_irq->pci_link_assert_count[1],
> hvm_irq->pci_link_assert_count[2],
> hvm_irq->pci_link_assert_count[3]);
> -printk("Callback via %i:%#"PRIx32",%s ass
On 07.01.2022 13:55, David Vrabel wrote:
> Include the type of the callback via and the per-VCPU upcall vector.
>
> Signed-off-by: David Vrabel
Reviewed-by: Jan Beulich
On 06/01/2022 16:48, Jan Beulich wrote:
On 06.01.2022 16:54, David Vrabel wrote:
The Windows XENBUS driver sets the per-VCPU LAPIC vector for event
channel interrupts using the HVMOP_set_evtchn_upcall_vector hypercall
(rather than using a vector-type callback in the CALLBACK_IRQ HVM
parameter si
flight 167625 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Amazon's guest transparent live migration work needs another save
record (for event channel upcall vectors). Reserve another HVM context
save record ID for this.
Signed-off-by: David Vrabel
---
I've added it to the end, keeping the unused ID at 21.
---
xen/include/public/arch-x86/hvm/save.h | 2
Include the type of the callback via and the per-VCPU upcall vector.
Signed-off-by: David Vrabel
---
v2:
- fix style
- make upcall vector output distinguishable from logs prior to this patch
- use fewer lines for callback via.
---
xen/arch/x86/hvm/irq.c | 49 +
flight 167624 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167624/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167619
test-amd64-amd64-qemuu-nested-amd 20
On 06/01/2022 16:00, Jan Beulich wrote:
> On 06.01.2022 16:08, James Dingwall wrote:
On Wed, Jul 21, 2021 at 12:59:11PM +0200, Jan Beulich wrote:
> On 21.07.2021 11:29, James Dingwall wrote:
On 06.01.2022 16:08, James Dingwall wrote:
>>> On Wed, Jul 21, 2021 at 12:59:11PM +0200, Jan Beulich wrote:
>>>
On 21.07.2021 11:29, James Dingwall wrote:
On 07.01.22 12:30, Andrew Cooper wrote:
On 07/01/2022 10:47, Juergen Gross wrote:
This small series is a followup to the series sent recently:
https://lists.xen.org/archives/html/xen-devel/2022-01/threads.html#00110
It contains the last cleanups related to struct file and can only be
applied a
On 09.12.21 21:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
You can find the RFC-V3 patch series at [1],[2] and [3].
The corresponding Xen support (for both Dom0 and DomU) is already committed and
is available in mainline Xen since the following commit:
57f87857dc2de4
On 07/01/2022 10:47, Juergen Gross wrote:
> This small series is a followup to the series sent recently:
>
> https://lists.xen.org/archives/html/xen-devel/2022-01/threads.html#00110
>
> It contains the last cleanups related to struct file and can only be
> applied after the Xen libraries have stopp
On 04.01.22 09:46, Jan Beulich wrote:
The hypervisor has been supplying this information for a couple of major
releases. Make use of it. The need to set a flag in the capabilities
field also points out that the prior setting of that field from the
hypervisor interface's gbl_caps one was wrong, so
The event channel specific union member in struct file is no longer
needed, so remove it
Signed-off-by: Juergen Gross
---
include/lib.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/lib.h b/include/lib.h
index cbfeea3..b82e285 100644
--- a/include/lib.h
+++ b/include/lib.h
@@ -180,7
The event channel specific union member in struct file is no longer
needed, so remove it together with the associated structure
definitions.
Signed-off-by: Juergen Gross
---
include/lib.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/lib.h b/include/lib.h
index 7a0546b
This small series is a followup to the series sent recently:
https://lists.xen.org/archives/html/xen-devel/2022-01/threads.html#00110
It contains the last cleanups related to struct file and can only be
applied after the Xen libraries have stopped using the related union
members.
Juergen Gross (
Mini-OS and libevtchn are using implementation details of each other.
Change that by letting libevtchn use the new get_file_from_fd()
function and the generic dev pointer of struct file from Mini-OS.
By using private struct declarations Mini-OS will be able to drop the
libevtchn specific definitio
This small series removes some hard coupling of the Xen build with some
Mini-OS internals, especially the struct file layout and the internal
organization of the file handling.
This series depends on the Mini-OS series posted recently:
https://lists.xen.org/archives/html/xen-devel/2022-01/threads
libgnttab is using implementation details of Mini-OS. Change that by
letting libgnttab use the new get_file_from_fd() function and the
generic dev pointer of struct file from Mini-OS.
Signed-off-by: Juergen Gross
---
tools/libs/gnttab/minios.c | 48 ++
1 file
Hi,
On 07/01/2022 00:02, Stefano Stabellini wrote:
On Thu, 6 Jan 2022, Julien Grall wrote:
On 06/01/2022 14:03, Jan Beulich wrote:
On 06.01.2022 08:13, Juergen Gross wrote:
On 06.01.22 01:40, Stefano Stabellini wrote:
Hi all,
Today Xen dom0less guests are not "Xen aware": the hypervisor nod
flight 167623 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167623/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167615
Tests which did not succee
flight 167627 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167627/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9dd14fc91c174eae87fd122c7ac70073a363527f
baseline version:
ovmf 079a58276b98dc97ca363
flight 167622 xen-unstable real [real]
flight 167626 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167622/
http://logs.test-lab.xenproject.org/osstest/logs/167626/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 07.01.2022 09:03, Jan Beulich wrote:
> Please point out backports you find missing from the respective staging
> branch, but which you consider relevant. With Ian's departure, tool
> stack backports (if any) will need some extra care. I'll try to deal
> with requests, but I may seek assistance i
All,
the releases are about due. Since 4.14's general support period ends
later in January, I intend to delay the release by about two weeks to
cover the full time range. Since it's a little easier to "batch"
releases, I also intend to keep 4.15.2 aligned with 4.14.4.
Please point out backports y
54 matches
Mail list logo
