Hi Vikram,
On 02/09/2021 07:05, Vikram Garhwal wrote:
Keep libfdt library functionalities after boot of hw_domain. This is done to
access fdt library function which are required for adding device tree overlay
nodes for dynamic programming of nodes.
AFAICT, the new feature will be mostly
flight 165691 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165691/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Vikram,
On 02/09/2021 07:05, Vikram Garhwal wrote:
Xen is missing fdt overlay functionalities. FDT overlay is required for changing
the device tree nodes during run-time.
fdt_overlay.c file is copied from Linux tree's following patch:
commit: 6e9c9686d826564f44c93cdd6f111b1c0a9dc224
On 20/10/2021 11:36, Jan Beulich wrote:
> x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
> mode (physical vs clustered) depends on iommu_intremap, that variable
> needs to be set to off as soon as we know we can't / won't enable the
> IOMMU, i.e. in particular when
> -
flight 165684 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165684/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 165681
Hi Hongda,
Title: I would suggest the following title:
xen/arm: vgic: Ignore write access to ICPENDR*
On 20/10/2021 11:10, Hongda Deng wrote:
Currently, Xen will return IO unhandled when guests access GICD ICPENRn
registers. This will raise a data abort inside guest. For Linux Guest,
these
Hi Vikram,
Apologies for the late answer. I was away most of September and still
catching up with my e-mails.
On 02/09/2021 07:05, Vikram Garhwal wrote:
Change function type of following function to access during runtime:
1. handle_device_interrupt()
2. map_irq_to_domain()
3.
flight 165690 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165690/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6893865b3010bb6192f732643c4b8ba026726d07
baseline version:
ovmf
On Wed, 20 Oct 2021, Ian Jackson wrote:
> Bertrand Marquis writes ("Re: [PATCH v2 1/1] xen/pci: Install vpci handlers
> on x86 and fix exit path"):
> > > On 20 Oct 2021, at 08:16, Jan Beulich wrote:
> > > I'm inclined to suggest s/exit/error/ in the title though (and maybe
> > > also
Hi Vikram
On 02/09/2021 07:05, Vikram Garhwal wrote:
Remove static function type from overlay_get_target().
Please explain why this is necessary. But if we really need then...
Signed-off-by: Vikram Garhwal
---
xen/common/libfdt/fdt_overlay.c | 2 +-
xen/include/xen/libfdt/libfdt.h | 2
> -Original Message-
> From: Julien Grall
> Sent: 2021年10月21日 1:45
> To: Hongda Deng ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
>
> Subject: Re: [PATCH v3] xen/arm: vgic to ignore GICD ICPENDRn registers
> access
>
> Hi Hongda,
>
>
flight 165694 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 165682
build-i386-xsm
flight 165687 linux-5.4 real [real]
flight 165695 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165687/
http://logs.test-lab.xenproject.org/osstest/logs/165695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
flight 165692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165684
test-armhf-armhf-libvirt 16
flight 165693 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165693/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165679
test-armhf-armhf-libvirt 16
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Wednesday, October 20, 2021 7:11 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Wei Chen ; Bertrand Marquis
>
> Subject: Re: [PATCH v2 4/6] xen/arm: if direct-map domain use native
>
On Fri, 15 Oct 2021 16:30:19 -0700, Luis Chamberlain wrote:
> Jens,
>
> I had last split up patches into 7 groups, but at this point now
> most changes are merged except a few more drivers. Instead of creating
> a new patch set for each of the 7 groups I'm creating 3 new groups of
> patches now:
On 20.10.2021 01:34, Andrew Cooper wrote:
> On 22/09/2021 15:36, Jan Beulich wrote:
>> Doing this in amd_iommu_prepare() is too late for it, in particular, to
>> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
>> to do. Moving it immediately ahead of
On 20.10.2021 09:02, Juergen Gross wrote:
> On 18.10.21 17:28, Juergen Gross wrote:
>> On 18.10.21 14:58, Jan Beulich wrote:
>>> On 15.10.2021 14:51, Juergen Gross wrote:
--- a/.gitignore
+++ b/.gitignore
@@ -332,10 +332,12 @@ xen/include/asm-x86/asm-macros.h
Hi,
> On 20 Oct 2021, at 08:16, Jan Beulich wrote:
>
> On 19.10.2021 18:08, Bertrand Marquis wrote:
>> Xen might not be able to discover at boot time all devices or some devices
>> might appear after specific actions from dom0.
>> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal
On 18.10.21 17:28, Juergen Gross wrote:
On 18.10.21 14:58, Jan Beulich wrote:
On 15.10.2021 14:51, Juergen Gross wrote:
--- a/.gitignore
+++ b/.gitignore
@@ -332,10 +332,12 @@ xen/include/asm-x86/asm-macros.h
xen/include/compat/*
xen/include/config/
xen/include/generated/
On 20.10.21 09:11, Jan Beulich wrote:
On 20.10.2021 09:02, Juergen Gross wrote:
On 18.10.21 17:28, Juergen Gross wrote:
On 18.10.21 14:58, Jan Beulich wrote:
On 15.10.2021 14:51, Juergen Gross wrote:
--- a/.gitignore
+++ b/.gitignore
@@ -332,10 +332,12 @@ xen/include/asm-x86/asm-macros.h
> From: Jan Beulich
> Sent: Tuesday, October 19, 2021 8:52 PM
>
> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
> order violation when the PoD lock is held around it. Hence such flushing
> needs
On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those
On Wed, Oct 20, 2021 at 07:57:15AM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 20 Oct 2021, at 08:49, Roger Pau Monné wrote:
> >
> > On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
> >> Xen might not be able to discover at boot time all devices or some devices
> >>
On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those
On 19.10.2021 18:08, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those devices where not
On 20.10.2021 01:34, Andrew Cooper wrote:
> On 22/09/2021 15:36, Jan Beulich wrote:
>> Doing this in amd_iommu_prepare() is too late for it, in particular, to
>> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
>> to do. Moving it immediately ahead of
Hi Roger,
> On 20 Oct 2021, at 09:08, Roger Pau Monné wrote:
>
> On Wed, Oct 20, 2021 at 07:57:15AM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 20 Oct 2021, at 08:49, Roger Pau Monné wrote:
>>>
>>> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
Xen might not
On Fri, Oct 15, 2021 at 11:48:33AM +0200, Jan Beulich wrote:
> On 15.10.2021 11:39, Jan Beulich wrote:
> > On 22.09.2021 10:21, Roger Pau Monne wrote:
> >> --- a/xen/include/public/domctl.h
> >> +++ b/xen/include/public/domctl.h
> >> @@ -87,14 +87,22 @@ struct xen_domctl_createdomain {
> >>
On Tue, Oct 19, 2021 at 05:06:27PM +0200, Jan Beulich wrote:
> On 19.10.2021 15:53, Roger Pau Monné wrote:
> > On Tue, Oct 19, 2021 at 02:52:27PM +0200, Jan Beulich wrote:
> >> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
> >> write_p2m_entry() -> p2m_flush_nestedp2m()
Hi Roger,
> On 20 Oct 2021, at 08:49, Roger Pau Monné wrote:
>
> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
>> Xen might not be able to discover at boot time all devices or some devices
>> might appear after specific actions from dom0.
>> In this case dom0 can use the
flight 165682 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165682/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 17 guest-stop fail REGR. vs. 165670
Tests which did not
flight 165685 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165685/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 37a33f02aa1ab89f392da7d06ec3578fda1b6182
baseline version:
ovmf
This patch serie is a follow-up after various findings on d59168dc05
("xen/arm: Enable the existing x86 virtual PCI support for ARM") as of
agreed in [1].
It does the following:
- enable vpci_add_handlers on x86 and not only on arm
- remove __hwdom_init flag for vpci_add_handlers
- add missing
Xen might not be able to discover at boot time all devices or some devices
might appear after specific actions from dom0.
In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
PCI devices to Xen.
As those devices where not known from Xen before, the vpci handlers must
be properly
On Fri, Oct 15, 2021 at 12:05:06PM +0200, Jan Beulich wrote:
> On 22.09.2021 10:21, Roger Pau Monne wrote:
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2649,7 +2649,8 @@ void __init create_domUs(void)
> > .max_evtchn_port = -1,
> >
x2apic_bsp_setup() gets called ahead of iommu_setup(), and since x2APIC
mode (physical vs clustered) depends on iommu_intremap, that variable
needs to be set to off as soon as we know we can't / won't enable the
IOMMU, i.e. in particular when
- parsing of the respective ACPI tables failed,
-
flight 165686 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165686/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 6809998c5f8f1d2e26ac9e867af8ac71e7a66cf2
baseline version:
xen
Currently, Xen will return IO unhandled when guests access GICD ICPENRn
registers. This will raise a data abort inside guest. For Linux Guest,
these virtual registers will not be accessed. But for Zephyr, in its
GIC initialization code, these virtual registers will be accessed. And
zephyr guest
flight 165683 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 20.10.2021 12:05, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those devices where not
On 20.10.2021 10:27, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
>> Xen might not be able to discover at boot time all devices or some devices
>> might appear after specific actions from dom0.
>> In this case dom0 can use the PHYSDEVOP_pci_device_add
On 20.10.2021 10:39, Bertrand Marquis wrote:
>> On 20 Oct 2021, at 09:34, Jan Beulich wrote:
>> On 20.10.2021 10:27, Roger Pau Monné wrote:
>>> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
On Wed, Oct 20, 2021 at 11:05:37AM +0100, Bertrand Marquis wrote:
> Xen might not be able to discover at boot time all devices or some devices
> might appear after specific actions from dom0.
> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
> PCI devices to Xen.
> As those
Hi,
> On 20 Oct 2021, at 09:34, Jan Beulich wrote:
>
> On 20.10.2021 10:27, Roger Pau Monné wrote:
>> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
>>> Xen might not be able to discover at boot time all devices or some devices
>>> might appear after specific actions from
On Wed, Oct 20, 2021 at 08:39:48AM +, Bertrand Marquis wrote:
> Hi,
>
> > On 20 Oct 2021, at 09:34, Jan Beulich wrote:
> >
> > On 20.10.2021 10:27, Roger Pau Monné wrote:
> >> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote:
> >>> Xen might not be able to discover at boot
From: Julien Grall
Commit 939775cfd3 "handle dying domains in live update" was meant to
handle gracefully dying domain. However, the @releaseDomain watch
will end up to be sent as soon as we finished to restore Xenstored
state.
This may be before Xen reports the domain to be dying (such as if
Hi all,
On 23/09/2021 08:56, Julien Grall wrote:
On 23/09/2021 12:23, Roger Pau Monné wrote:
On Wed, Sep 22, 2021 at 06:46:25PM +0500, Julien Grall wrote:
I thought a bit more and looked at the code (I don't have access to a
test
machine at the moment). I think there is indeed a problem.
flight 165689 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165689/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Penny,
On 15/10/2021 04:09, Penny Zheng wrote:
From: Stefano Stabellini
Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all direct-map domains(including Dom0).
Considering that
On 20.10.21 12:57, Jan Beulich wrote:
On 20.10.2021 10:04, Roger Pau Monné wrote:
On Fri, Oct 15, 2021 at 11:48:33AM +0200, Jan Beulich wrote:
On 15.10.2021 11:39, Jan Beulich wrote:
On 22.09.2021 10:21, Roger Pau Monne wrote:
--- a/xen/include/public/domctl.h
+++
On 20.10.2021 12:14, Roger Pau Monné wrote:
> On Fri, Oct 15, 2021 at 12:05:06PM +0200, Jan Beulich wrote:
>> On 22.09.2021 10:21, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -750,7 +750,8 @@ static struct domain *__init create_dom0(const module_t
On 22.09.2021 10:21, Roger Pau Monne wrote:
> Introduce a new domain create field so that toolstack can specify the
> maximum grant table version usable by the domain. This is plumbed into
> xl and settable by the user as max_grant_version.
>
> Previously this was only settable on a per host
On Tue, 19 Oct 2021 22:48:19 +0100,
Josef Johansson wrote:
>
> From: Josef Johansson
>
>
> PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
>
> commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions") introduce functions pci_msi_update_mask() and
>
On Wed, Oct 20, 2021 at 12:57:11PM +0200, Jan Beulich wrote:
> On 20.10.2021 10:04, Roger Pau Monné wrote:
> > On Fri, Oct 15, 2021 at 11:48:33AM +0200, Jan Beulich wrote:
> >> On 15.10.2021 11:39, Jan Beulich wrote:
> >>> On 22.09.2021 10:21, Roger Pau Monne wrote:
> ---
Bertrand Marquis writes ("Re: [PATCH v2 1/1] xen/pci: Install vpci handlers on
x86 and fix exit path"):
> > On 20 Oct 2021, at 08:16, Jan Beulich wrote:
> > I'm inclined to suggest s/exit/error/ in the title though (and maybe
> > also s/path/paths/), which would be easy enough to do while
On 20.10.2021 10:04, Roger Pau Monné wrote:
> On Fri, Oct 15, 2021 at 11:48:33AM +0200, Jan Beulich wrote:
>> On 15.10.2021 11:39, Jan Beulich wrote:
>>> On 22.09.2021 10:21, Roger Pau Monne wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -87,14 +87,22
Hi Penny,
On 15/10/2021 04:09, Penny Zheng wrote:
From: Stefano Stabellini
We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.
So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to
~Bertrand Marquis writes ("Re: [PATCH v3] xen/arm: vgic to ignore GICD ICPENDRn
registers access"):
> [+Ian]
> > On 20 Oct 2021, at 11:10, Hongda Deng wrote:
> >
> > Currently, Xen will return IO unhandled when guests access GICD ICPENRn
> > registers. This will raise a data abort inside guest.
Hi Ian,
On 20/10/2021 14:30, Ian Jackson wrote:
~Bertrand Marquis writes ("Re: [PATCH v3] xen/arm: vgic to ignore GICD ICPENDRn
registers access"):
[+Ian]
On 20 Oct 2021, at 11:10, Hongda Deng wrote:
Currently, Xen will return IO unhandled when guests access GICD ICPENRn
registers. This
flight 165688 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165688/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4fdf843c75d297fe892f989009b3d3e397ccfd55
baseline version:
ovmf
Hi Bertrand,
On 20/10/2021 11:05, Bertrand Marquis wrote:
Xen might not be able to discover at boot time all devices or some devices
might appear after specific actions from dom0.
In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some
PCI devices to Xen.
As those devices where
Hi Hongda,
[+Ian]
> On 20 Oct 2021, at 11:10, Hongda Deng wrote:
>
> Currently, Xen will return IO unhandled when guests access GICD ICPENRn
> registers. This will raise a data abort inside guest. For Linux Guest,
> these virtual registers will not be accessed. But for Zephyr, in its
> GIC
Hi, Marc,
Adding Juergen and Boris since this involves Xen.
On Wed, Oct 20, 2021 at 8:51 AM Marc Zyngier wrote:
>
> On Tue, 19 Oct 2021 22:48:19 +0100,
> Josef Johansson wrote:
> >
> > From: Josef Johansson
> >
> >
> > PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
> >
> > commit
Julien Grall writes ("Re: [PATCH v3] xen/arm: vgic to ignore GICD ICPENDRn
registers access"):
> TL;DR: This is a bug fix and I agree that this should be included in 4.16.
Thank you very much for the detailed and helpful reply.
Release-Acked-by: Ian Jackson
Julien Grall writes ("[PATCH for-4.16] tools/xenstored: Ignore domain we were
unable to restore"):
> From: Julien Grall
>
> Commit 939775cfd3 "handle dying domains in live update" was meant to
> handle gracefully dying domain. However, the @releaseDomain watch
> will end up to be sent as soon
Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Signed-off-by: Jakub Kicinski
---
CC:
68 matches
Mail list logo
