On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote:
> The two are really meant to be independent settings; iov_supports_xt()
> using || instead of && was simply wrong. The corrected check is,
> however, redundant, just like the (correct) one in iov_detect(): These
> hook functions are
On Sun, 2021-10-24 at 21:25 -0400, Jason Andryuk wrote:
> commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions") introduce functions pci_msi_update_mask() and
> pci_msix_write_vector_ctrl() that is missing checks for
> pci_msi_ignore_mask that exists in commit
flight 165845 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165845/
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
On 22.10.21 11:28, Andrew Cooper wrote:
On 22/10/2021 07:47, Juergen Gross wrote:
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are
Juergen Gross writes ("Re: [PATCH] OSStest: explicitly enable building
qemu-traditional"):
> On 19.10.21 15:04, Ian Jackson wrote:
> > OOI, have you done any kind of test on this ?
>
> No, this was a pure "lets do things in a similar way as the other
> options" approach.
>
> > I'm kind of
It is planned to no longer build qemu-traditional per default.
In order to be able to continue running tests with ioemu-stubdom run
configure with --enable-qemu-traditional.
Signed-off-by: Juergen Gross
---
V2:
- set --enable-qemu-traditional on x86 only (Ian Jackson)
---
ts-xen-build | 6
flight 165848 linux-linus real [real]
flight 165857 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165848/
http://logs.test-lab.xenproject.org/osstest/logs/165857/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Oct 22, 2021 at 03:59:51PM -0700, Stefano Stabellini wrote:
> Clarify that xen-devel is the only official communication channel.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/source/communication-practice.rst
> b/source/communication-practice.rst
> index 70f5b8c..356df7a
On Thu, Oct 21, 2021 at 11:58:37AM +0200, Jan Beulich wrote:
> The value it returns may change from true to false in case
> iommu_enable_x2apic() fails and, as a side effect, clears iommu_intremap
> (as can happen at least on AMD). Latch the return value from the first
> invocation to replace the
Hi, Roger!
On 13.10.21 13:11, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the configuration space. For example, BARs
On Mon, Oct 25, 2021 at 3:44 AM David Woodhouse wrote:
>
> On Sun, 2021-10-24 at 21:25 -0400, Jason Andryuk wrote:
> > commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> > functions") introduce functions pci_msi_update_mask() and
> > pci_msix_write_vector_ctrl() that is missing
On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> The PCI device remove path may now be used by PVH on ARM, so the
> assert is no longer valid.
I think ti might be worth saying that this is a preparatory change and
that PCI passthrough
On Thu, Oct 21, 2021 at 06:12:03AM -0700, Jakub Kicinski wrote:
> 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
flight 165852 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165852/
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 Fri, Oct 15, 2021 at 08:04:56AM +0200, Jan Beulich wrote:
> On 13.10.2021 15:51, Roger Pau Monné wrote:
> > On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
> >> --- a/xen/drivers/vpci/header.c
> >> +++ b/xen/drivers/vpci/header.c
> >> @@ -445,6 +445,55 @@ static void
On Mon, 2021-10-25 at 13:43 +0200, Roger Pau Monné wrote:
> It's kind of optional for HVM guests, as it depends on
> XENFEAT_hvm_pirqs, which sadly gets unconditionally set for HVM
> guests, thus dropping any benefits from having hardware assisted APIC
> virtualization or posted interrupts
On Mon, Oct 25, 2021 at 08:44:52AM +0100, David Woodhouse wrote:
> On Sun, 2021-10-24 at 21:25 -0400, Jason Andryuk wrote:
> > commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> > functions") introduce functions pci_msi_update_mask() and
> > pci_msix_write_vector_ctrl() that is
On Mon, Oct 25, 2021 at 12:53:31PM +0100, David Woodhouse wrote:
> On Mon, 2021-10-25 at 13:43 +0200, Roger Pau Monné wrote:
> > It's kind of optional for HVM guests, as it depends on
> > XENFEAT_hvm_pirqs, which sadly gets unconditionally set for HVM
> > guests, thus dropping any benefits from
On Mon, 2021-10-25 at 14:58 +0200, Roger Pau Monné wrote:
> On Mon, Oct 25, 2021 at 12:53:31PM +0100, David Woodhouse wrote:
> > On Mon, 2021-10-25 at 13:43 +0200, Roger Pau Monné wrote:
> > > It's kind of optional for HVM guests, as it depends on
> > > XENFEAT_hvm_pirqs, which sadly gets
Hi, Roger!
On 25.10.21 16:14, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The PCI device remove path may now be used by PVH on ARM, so the
>> assert is no longer valid.
> I think ti might be worth saying
On Mon, Oct 25, 2021 at 02:02:38PM +0100, David Woodhouse wrote:
> On Mon, 2021-10-25 at 14:58 +0200, Roger Pau Monné wrote:
> > On Mon, Oct 25, 2021 at 12:53:31PM +0100, David Woodhouse wrote:
> > > On Mon, 2021-10-25 at 13:43 +0200, Roger Pau Monné wrote:
> > > > It's kind of optional for HVM
Hi, Julien!
On 13.10.21 19:17, Julien Grall wrote:
> Hi Oleksandr,
>
> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> PCI host bridges are special devices in terms of implementing PCI
>> passthrough. According to [1] the current implementation depends
Hi, Roger!
Could you please take a look at the below?
Jan was questioning the per BAR range set approach, so it
is crucial for the maintainer (you) to answer here.
Thank you in advance,
Oleksandr
On 30.09.21 10:52, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Instead of
On Sun, Oct 24, 2021 at 9:26 PM Jason Andryuk wrote:
>
> commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions") introduce functions pci_msi_update_mask() and
> pci_msix_write_vector_ctrl() that is missing checks for
> pci_msi_ignore_mask that exists in commit
On Mon, Oct 25, 2021 at 09:38:00AM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 13.10.21 13:11, Roger Pau Monné wrote:
> > On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> In order for vPCI to work it needs to
On 25.10.21 16:40, Roger Pau Monné wrote:
> On Mon, Oct 25, 2021 at 09:38:00AM +, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 13.10.21 13:11, Roger Pau Monné wrote:
>>> On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, Julien!
On 13.10.21 18:30, Julien Grall wrote:
> Hi Oleksandr,
>
> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> vPCI may map and unmap PCI device memory (BARs) being passed through which
>> may take a lot of time. For this those operations may be
On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Arm's PCI passthrough implementation doesn't support legacy interrupts,
> but MSI/MSI-X. This can be the case for other platforms too.
> For that reason introduce a new
Hi, Roger!
On 25.10.21 16:22, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Arm's PCI passthrough implementation doesn't support legacy interrupts,
>> but MSI/MSI-X. This can be the case for other
On Mon, Oct 25, 2021 at 01:38:19PM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 25.10.21 16:22, Roger Pau Monné wrote:
> > On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> Arm's PCI passthrough implementation
On Thu, Sep 30, 2021 at 10:52:16AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having different
> handlers for different domains, e.g. hwdom
Juergen Gross writes ("[PATCH v2] OSStest: explicitly enable building
qemu-traditional"):
> It is planned to no longer build qemu-traditional per default.
>
> In order to be able to continue running tests with ioemu-stubdom run
> configure with --enable-qemu-traditional.
>
> Signed-off-by:
On Fri, Oct 22, 2021 at 01:05:35PM -0700, Stefano Stabellini wrote:
> On Fri, 22 Oct 2021, Anthony PERARD wrote:
> > On Thu, Oct 21, 2021 at 04:08:39PM -0700, Stefano Stabellini wrote:
> > > diff --git a/automation/scripts/qemu-alpine-x86_64.sh
> > > b/automation/scripts/qemu-alpine-x86_64.sh
> >
On 10/25/21 14:27, Jason Andryuk wrote:
> On Sun, Oct 24, 2021 at 9:26 PM Jason Andryuk wrote:
>> commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
>> functions") introduce functions pci_msi_update_mask() and
>> pci_msix_write_vector_ctrl() that is missing checks for
>>
flight 165850 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165850/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165825
test-armhf-armhf-libvirt 16
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller :
On Fri, 22 Oct 2021 16:31:39 -0700 you wrote:
> The tx queues are not stopped during the live migration. As a result, the
> ndo_start_xmit() may access netfront_info->queues which is freed by
>
Stefano Stabellini writes ("Re: [XEN PATCH] automation: actually build with
clang for ubuntu-focal-clang* jobs"):
> On Fri, 22 Oct 2021, Stefano Stabellini wrote:
> > On Fri, 22 Oct 2021, Anthony PERARD wrote:
> > > Signed-off-by: Anthony PERARD
> >
> > Reviewed-by: Stefano Stabellini
>
> FYI
The guest may access the pv vcpu_time_info immediately after
VCPUOP_register_vcpu_info. This is to borrow the idea of
VCPUOP_register_vcpu_time_memory_area, where the
force_update_vcpu_system_time() is called immediately when the new memory
area is registered.
Otherwise, we may observe clock
flight 165861 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165861/
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
On 10/25/21 03:25, Jason Andryuk wrote:
> On Sun, Oct 24, 2021 at 2:55 PM Josef Johansson wrote:
>
>> I ended up with this patch, I also masked pci_set_mask and
>> pci_set_unmask, even though patching __pci_restore_msi_state and
>> __pci_restore_msi_state solved this problem, I found that it did
flight 165855 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165855/
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 165862 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165862/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b80c17b62d989ec00e528c6307c726ce6800bcc4
baseline version:
ovmf
On Mon, 25 Oct 2021, Anthony PERARD wrote:
> On Fri, Oct 22, 2021 at 01:05:35PM -0700, Stefano Stabellini wrote:
> > On Fri, 22 Oct 2021, Anthony PERARD wrote:
> > > On Thu, Oct 21, 2021 at 04:08:39PM -0700, Stefano Stabellini wrote:
> > > > diff --git a/automation/scripts/qemu-alpine-x86_64.sh
>
Hi all,
This small patch series introduces a new QEMU-based test to Gitlab-CI.
It uses QEMU to emulate an x86_64 machine and run Xen, Dom0 and start a
DomU. It is very similar to the existing qemu-alpine-arm64-gcc test but
based on x86_64 rather than ARM64. I think it is important because all
the
From: Stefano Stabellini
Introduce a test based on QEMU to run Xen, Dom0 and start a DomU.
This is similar to the existing qemu-alpine-arm64.sh script and test.
The only differences are:
- use Debian's qemu-system-x86_64 (on ARM we build our own)
- use ipxe instead of u-boot and ImageBuilder
From: Stefano Stabellini
It is the same as the existing ARM64 alpine 3.12 test-artifact. It is
used to export an Alpine rootfs for Dom0 used for testing.
Also add the exporting job to build.yaml so that the binaries can be
used during gitlab-ci runs.
Signed-off-by: Stefano Stabellini
From: Stefano Stabellini
Build a 5.10 kernel to be used as Dom0 and DomU kernel for testing. This
is almost the same as the existing ARM64 recipe for Linux 5.9, the
only differences are:
- upgrade to latest 5.10.x stable
- force Xen modules to built-in (on ARM it was already done by defconfig)
On Mon, 25 Oct 2021, Roger Pau Monné wrote:
> On Fri, Oct 22, 2021 at 03:59:51PM -0700, Stefano Stabellini wrote:
> > Clarify that xen-devel is the only official communication channel.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > diff --git a/source/communication-practice.rst
> >
Clarify that xen-devel is the only official communication channel.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove mentions of #xendevel on OFTC
diff --git a/source/communication-practice.rst
b/source/communication-practice.rst
index 70f5b8c..2ce2a4e 100644
---
On 10/25/2021 6:02 PM, Guenter Roeck wrote:
On 10/25/21 4:55 PM, Dmitry Osipenko wrote:
26.10.2021 02:29, Florian Fainelli пишет:
On 6/4/21 7:03 AM, Lee Jones wrote:
This is a rebase/refresh of a set sent out, reviewed,
then forgotten about. It's still considered useful.
Here is an
On 19/10/2021 08:07, Jan Beulich wrote:
> From: Thomas Gleixner
>
> On recent Intel systems the HPET stops working when the system reaches PC10
> idle state.
>
> The approach of adding PCI ids to the early quirks to disable HPET on
> these systems is a whack a mole game which makes no sense.
>
>
On 6/4/21 7:03 AM, Lee Jones wrote:
> This is a rebase/refresh of a set sent out, reviewed,
> then forgotten about. It's still considered useful.
>
> Here is an excerpt from the previous attempt:
>
> "Hi Russell, ARM SoC maintainers,
>
> here's the full set of patches that remove
On Mon, 25 Oct 2021, Juergen Gross wrote:
> On 22.10.21 21:41, Stefano Stabellini wrote:
> > +Juergen
> >
> > On Fri, 22 Oct 2021, Andrew Cooper wrote:
> > > On 22/10/2021 00:08, Stefano Stabellini wrote:
> > > > +# build depends
> > > > +RUN apt-get update && \
> > > > +apt-get --quiet --yes
flight 165858 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165858/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 165848 pass in 165858
test-amd64-amd64-xl-rtds 20
On 10/25/21 4:55 PM, Dmitry Osipenko wrote:
26.10.2021 02:29, Florian Fainelli пишет:
On 6/4/21 7:03 AM, Lee Jones wrote:
This is a rebase/refresh of a set sent out, reviewed,
then forgotten about. It's still considered useful.
Here is an excerpt from the previous attempt:
"Hi Russell,
55 matches
Mail list logo
