On 21.01.22 10:01, Roger Pau Monne wrote:
There's no point in disabling x2APIC mode when running as a Xen HVM
guest, just enable it when available.
Remove some unneeded wrapping around the detection functions, and
simply provide a xen_x2apic_available helper that's a wrapper around
flight 167988 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167988/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167979
test-armhf-armhf-libvirt 16
On Wed, 2 Feb 2022, Stefano Stabellini wrote:
> On Wed, 2 Feb 2022, Ayan Kumar Halder wrote:
> > For instructions on MMIO regions emulated by Xen, Xen reads the
> > remaining bits of the HSR. It determines if the instruction is to be
> > ignored, retried or decoded. If it gets an error while
On Wed, 2 Feb 2022, Ayan Kumar Halder wrote:
> When an instruction is trapped in Xen due to translation fault, Xen checks if
> the ISS is valid. If not, Xen tries to resolve the translation fault using
> p2m page tables. In case if it is a data abort, Xen will try to map the mmio
> region to the
On Wed, 2 Feb 2022, Ayan Kumar Halder wrote:
> For instructions on MMIO regions emulated by Xen, Xen reads the
> remaining bits of the HSR. It determines if the instruction is to be
> ignored, retried or decoded. If it gets an error while decoding the
> instruction, then it sends an abort to the
flight 167987 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167987/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 167981
flight 167989 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167989/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 33189f05278345eab608ff56e87905bdeacdbd47
baseline version:
ovmf
flight 167986 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167986/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167978
test-armhf-armhf-libvirt 16
Hi,
On 02/02/2022 13:05, Ayan Kumar Halder wrote:
On 31/01/2022 19:37, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..f19fb46f72 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -23,16 +23,35 @@
#include
+#include
Hi Julien/Stefano,
On 02/02/2022 13:05, Ayan Kumar Halder wrote:
Hi Julien,
I have a question.
On 31/01/2022 19:37, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..f19fb46f72 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@
At the moment, Xen does not decode any of the arm64 instructions. This
means that hsr_dabt.isv = 0, Xen cannot handle those instructions. This
will lead to Xen abort the guests (from which those instructions
originated).
With this patch, Xen is able to decode ldr/str post indexing instructions.
When an instruction is trapped in Xen due to translation fault, Xen checks if
the ISS is valid. If not, Xen tries to resolve the translation fault using
p2m page tables. In case if it is a data abort, Xen will try to map the mmio
region to the guest (ie tries to emulate the mmio region).
If it is
For instructions on MMIO regions emulated by Xen, Xen reads the
remaining bits of the HSR. It determines if the instruction is to be
ignored, retried or decoded. If it gets an error while decoding the
instruction, then it sends an abort to the guest.
If the instruction is valid or successfully
Hi All,
I have split "[XEN v5] xen/arm64: io: Decode ldr/str post-indexing instructions"
into the following three patches :-
Ayan Kumar Halder (3):
xen/arm64: Decode ldr/str post increment operations
xen/arm64: io: Support instructions (for which ISS is not valid) on
emulated MMIO region
On Wed, Feb 02, 2022 at 03:19:13PM +, Jane Malalane wrote:
> On 01/02/2022 10:02, Roger Pau Monné wrote:
> > On Thu, Jan 27, 2022 at 04:01:33PM +, Jane Malalane wrote:
> >> diff --git a/tools/libs/light/libxl_types.idl
> >> b/tools/libs/light/libxl_types.idl
> >> index
On Tue, Jan 04, 2022 at 10:41:32AM +0100, Jan Beulich wrote:
> While it is okay for IOMMU page tables to get set up for guests starting
> in PoD mode, actual device assignment may only occur once all PoD
> entries have been removed from the P2M. So far this was enforced only
> for boot-time
On 02.02.2022 16:12, Oleksandr Andrushchenko wrote:
> On 02.02.22 17:08, Jan Beulich wrote:
>> On 02.02.2022 16:04, Oleksandr Andrushchenko wrote:
>>> Or do we want some additional code in MSI/MSI-X's control_write
>>> functions to set INTX bit there as well?
>> Well, yes, this is what Roger and I
On 02.02.2022 16:14, Roger Pau Monné wrote:
> On Tue, Jan 04, 2022 at 10:41:53AM +0100, Jan Beulich wrote:
>> Do away with the "pod_target_out_unlock" label. In particular by folding
>> if()-s, the logic can be expressed with less code (and no goto-s) this
>> way.
>>
>> Limit scope of "p2m",
On 01/02/2022 10:02, Roger Pau Monné wrote:
> On Thu, Jan 27, 2022 at 04:01:33PM +, Jane Malalane wrote:
>> Introduce a new per-domain creation x86 specific flag to
>> select whether hardware assisted virtualization should be used for
>> x{2}APIC.
>>
>> A per-domain option is added to xl in
On Tue, Jan 04, 2022 at 10:41:53AM +0100, Jan Beulich wrote:
> Do away with the "pod_target_out_unlock" label. In particular by folding
> if()-s, the logic can be expressed with less code (and no goto-s) this
> way.
>
> Limit scope of "p2m", constifying it at the same time.
Is this stale? I
On 02.02.22 17:08, Jan Beulich wrote:
> On 02.02.2022 16:04, Oleksandr Andrushchenko wrote:
>>
>> On 02.02.22 16:31, Jan Beulich wrote:
>>> On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
On 02.02.22 16:18, Jan Beulich wrote:
> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
On 02.02.2022 16:04, Oleksandr Andrushchenko wrote:
>
>
> On 02.02.22 16:31, Jan Beulich wrote:
>> On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
>>>
>>> On 02.02.22 16:18, Jan Beulich wrote:
On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
>> On 02.02.2022 13:49, Oleksandr
On 02.02.2022 15:45, Roger Pau Monne wrote:
> One of the boxes where I was attempting to boot Xen in PVH dom0 mode
> has quirky firmware, as it will handover with a PCI device with memory
> decoding enabled and a BAR of size 4K at address 0. Such BAR overlaps
> with a RAM range on the e820.
>
>
On 02.02.22 16:31, Jan Beulich wrote:
> On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
>>
>> On 02.02.22 16:18, Jan Beulich wrote:
>>> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
>> On 13.01.22 12:50, Roger Pau Monné
On Mon, 24 Jan 2022 10:10:48 +0100, Christoph Hellwig wrote:
> this series is posted early because it has wide-ranging changes and could use
> some
> early ACKs before -rc1.
>
> It changes the interface to the bio allocators to always pass a block_device
> and
> the operation, which is
One of the boxes where I was attempting to boot Xen in PVH dom0 mode
has quirky firmware, as it will handover with a PCI device with memory
decoding enabled and a BAR of size 4K at address 0. Such BAR overlaps
with a RAM range on the e820.
This interacts badly with the dom0 PVH build, as BARs
On 02.02.2022 15:27, Boris Ostrovsky wrote:
>
> On 2/1/22 5:57 AM, Jan Beulich wrote:
>> This started out with me noticing that "dom0_max_vcpus=" with
>> larger than the number of physical CPUs reported through ACPI tables
>> would not bring up the "excess" vCPU-s. Addressing this is the primary
On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
>
>
> On 02.02.22 16:18, Jan Beulich wrote:
>> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
> On 13.01.22 12:50, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at
On 2/1/22 5:57 AM, Jan Beulich wrote:
This started out with me noticing that "dom0_max_vcpus=" with
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s. Addressing this is the primary
purpose of the change; CPU maps handling is being
On 02.02.22 16:18, Jan Beulich wrote:
> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
>>> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
On 13.01.22 12:50, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
>> ---
On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
>> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
>>> On 13.01.22 12:50, Roger Pau Monné wrote:
On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/vpci/header.c
> +++
Hi, Roger!
On 13.01.22 15:23, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:50PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> At the moment, we always allocate an extra 16 slots for IO handlers
>> (see MAX_IO_HANDLER). So while adding IO trap handlers for
flight 167982 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167982/
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
Hi, Roger!
On 13.01.22 14:18, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:49PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> There are three originators for the PCI configuration space access:
>> 1. The domain that owns physical host bridge: MMIO
On 02.02.22 15:32, Jan Beulich wrote:
> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
>> On 13.01.22 12:50, Roger Pau Monné wrote:
>>> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@
On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
> On 13.01.22 12:50, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -491,6 +491,22 @@ static void cmd_write(const
On 02.02.22 12:53, Anthony PERARD wrote:
On Sun, Jan 30, 2022 at 09:43:38AM +0100, Juergen Gross wrote:
The tools/include/xen-external directory contains a header file from
FreeBSD used to generate Xen header files. This series is replacing the
complete directory by a single header with the
On 30.01.22 09:43, Juergen Gross wrote:
Today tools/include contains two basically identical header files
generated from the same source. They just differ by the used name space
and they are being generated from different Makefiles via a perl
script.
Prepare to have only one such header by
On 02.02.2022 13:13, Roger Pau Monné wrote:
> On Wed, Feb 02, 2022 at 10:42:22AM +0100, Jan Beulich wrote:
>> On 01.02.2022 13:45, Roger Pau Monne wrote:
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -554,6 +554,8 @@ int __must_check steal_page(struct domain *d, struct
>>>
flight 167981 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167981/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167975
Tests which did not
Hi, Roger!
On 13.01.22 13:35, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:48PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Assign SBDF to the PCI devices being passed through with bus 0.
>> The resulting topology is where PCIe devices reside on the bus
Hi, Jan!
On 12.01.22 17:39, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>> @@ -145,6 +148,53 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> }
>>
>> #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +int vpci_add_virtual_device(struct pci_dev *pdev)
>> +{
>> +
flight 167985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167985/
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 Julien,
I have a question.
On 31/01/2022 19:37, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 308650b400..f19fb46f72 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -23,16 +23,35 @@
#include
+#include "decode.h"
+
enum
Hi, Roger!
On 13.01.22 13:07, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:47PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Reset the command register when passing through a PCI device:
>> it is possible that when passing through a PCI device its memory
Hi, Roger!
On 13.01.22 12:50, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add basic emulation support for guests. At the moment only emulate
>> PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet
On Wed, Feb 02, 2022 at 10:42:22AM +0100, Jan Beulich wrote:
> On 01.02.2022 13:45, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
> > return (page_get_owner(page) == dom_io);
> > }
> >
> > +bool
On Sun, Jan 30, 2022 at 09:43:38AM +0100, Juergen Gross wrote:
> The tools/include/xen-external directory contains a header file from
> FreeBSD used to generate Xen header files. This series is replacing the
> complete directory by a single header with the same semantics.
>
> Juergen Gross (5):
>
Add a document to describe the rules for sending a proper patch.
As it contains all the information already being present in
docs/process/tags.pandoc remove that file.
Signed-off-by: Juergen Gross
---
docs/process/sending-patches.pandoc | 284
On 02.02.22 13:14, Jan Beulich wrote:
> On 02.02.2022 12:03, Oleksandr Andrushchenko wrote:
>> On 02.02.22 11:22, Jan Beulich wrote:
>>> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
From: Roger Pau Monne
This way the lock can be used to check whether vpci is present, and
On 02.02.22 13:11, Jan Beulich wrote:
> On 02.02.2022 11:44, Oleksandr Andrushchenko wrote:
>> Again, IMO, adding such a big piece of DEBUG code instead of
>> printing a single DEBUG message could be a bit expansive.
>> I still hear your concerns on *when* it is printed, but still think we can
On 02.02.2022 12:03, Oleksandr Andrushchenko wrote:
> On 02.02.22 11:22, Jan Beulich wrote:
>> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>>> From: Roger Pau Monne
>>>
>>> This way the lock can be used to check whether vpci is present, and
>>> removal can be performed while holding the
On 02.02.2022 11:44, Oleksandr Andrushchenko wrote:
> Again, IMO, adding such a big piece of DEBUG code instead of
> printing a single DEBUG message could be a bit expansive.
> I still hear your concerns on *when* it is printed, but still think we can
> allow that.
You do realize though that the
Hi, Jan!
On 02.02.22 11:22, Jan Beulich wrote:
> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>> From: Roger Pau Monne
>>
>> This way the lock can be used to check whether vpci is present, and
>> removal can be performed while holding the lock, in order to make
>> sure there are no
On 02.02.22 12:34, Roger Pau Monné wrote:
> On Wed, Feb 02, 2022 at 09:46:21AM +, Oleksandr Andrushchenko wrote:
> +gdprintk(XENLOG_G_DEBUG,
> + "%smap [%lx, %lx] -> %#"PRI_gfn" for %pd\n",
> + map->map ? "" : "un", s, e, gfn_x(start_gfn),
On Wed, Feb 02, 2022 at 09:46:21AM +, Oleksandr Andrushchenko wrote:
>
> >>> +gdprintk(XENLOG_G_DEBUG,
> >>> + "%smap [%lx, %lx] -> %#"PRI_gfn" for %pd\n",
> >>> + map->map ? "" : "un", s, e, gfn_x(start_gfn),
> >>> + map->d);
> >>
Hi, Roger!
On 02.02.22 11:45, Roger Pau Monné wrote:
> On Tue, Feb 01, 2022 at 06:25:08PM +0200, Oleksandr Andrushchenko wrote:
>> From: Roger Pau Monne
>>
>> This way the lock can be used to check whether vpci is present, and
>> removal can be performed while holding the lock, in order to make
Hi Jan,
On 02/02/2022 10:05, Jan Beulich wrote:
On 02.02.2022 10:57, Julien Grall wrote:
On 02/02/2022 09:42, Jan Beulich wrote:
On 01.02.2022 13:45, Roger Pau Monne wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
return
On 02.02.2022 10:57, Julien Grall wrote:
> On 02/02/2022 09:42, Jan Beulich wrote:
>> On 01.02.2022 13:45, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
>>> return (page_get_owner(page) == dom_io);
>>>
flight 167984 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167984/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 9ce3ef20b4f085a7dc8ee41b0fec6fdeced3773e
baseline version:
xen
flight 167978 xen-unstable real [real]
flight 167983 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167978/
http://logs.test-lab.xenproject.org/osstest/logs/167983/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi, Roger!
On 02.02.22 11:56, Roger Pau Monné wrote:
> On Wed, Feb 02, 2022 at 06:44:41AM +, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 12.01.22 17:15, Roger Pau Monné wrote:
>>> On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
@@ -108,11 +115,32 @@ int
Hi,
On 02/02/2022 09:42, Jan Beulich wrote:
On 01.02.2022 13:45, Roger Pau Monne wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
return (page_get_owner(page) == dom_io);
}
+bool is_memory_hole(unsigned long start, unsigned
On Wed, Feb 02, 2022 at 06:44:41AM +, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 12.01.22 17:15, Roger Pau Monné wrote:
> > On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
> >> @@ -108,11 +115,32 @@ int vpci_add_handlers(struct pci_dev *pdev)
> >>
On Wed, Feb 02, 2022 at 10:05:55AM +0100, Jan Beulich wrote:
> On 02.02.2022 09:44, Roger Pau Monné wrote:
> > On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
>
> Oleksandr, can you please clarify authorship here? The rule of thumb is
>
On 02.02.22 11:45, Jan Beulich wrote:
> On 02.02.2022 10:38, Oleksandr Andrushchenko wrote:
>> On 02.02.22 11:05, Jan Beulich wrote:
>>> On 02.02.2022 09:44, Roger Pau Monné wrote:
On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>>> +gdprintk(XENLOG_G_DEBUG,
>>> + "%smap [%lx, %lx] -> %#"PRI_gfn" for %pd\n",
>>> + map->map ? "" : "un", s, e, gfn_x(start_gfn),
>>> + map->d);
>> That's too chatty IMO, I could be fine with printing something along
>> this lines from
On 02.02.2022 10:38, Oleksandr Andrushchenko wrote:
> On 02.02.22 11:05, Jan Beulich wrote:
>> On 02.02.2022 09:44, Roger Pau Monné wrote:
>>> On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
>> Oleksandr, can you please clarify
On Tue, Feb 01, 2022 at 06:25:08PM +0200, Oleksandr Andrushchenko wrote:
> From: Roger Pau Monne
>
> This way the lock can be used to check whether vpci is present, and
> removal can be performed while holding the lock, in order to make
> sure there are no accesses to the contents of the vpci
On 01.02.2022 13:45, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
> return (page_get_owner(page) == dom_io);
> }
>
> +bool is_memory_hole(unsigned long start, unsigned long end)
> +{
> +unsigned int i;
>
Hi, Jan!
On 02.02.22 11:05, Jan Beulich wrote:
> On 02.02.2022 09:44, Roger Pau Monné wrote:
>> On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
> Oleksandr, can you please clarify authorship here? The rule of thumb is
> that From:
On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
> From: Roger Pau Monne
>
> This way the lock can be used to check whether vpci is present, and
> removal can be performed while holding the lock, in order to make
> sure there are no accesses to the contents of the vpci struct.
> Previously
On 02.02.2022 09:44, Roger Pau Monné wrote:
> On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
Oleksandr, can you please clarify authorship here? The rule of thumb is
that From: matches ...
>> Shrink critical section in vpci_{read/write}
Hi, Jan!
On 02.02.22 10:48, Jan Beulich wrote:
> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>> Oleksandr Andrushchenko (3):
>>rangeset: add RANGESETF_no_print flag
>>rangeset: add rangeset_reset helper function
>>vpci: shrink critical section in vpci_{read/write}
>>
>> Roger
On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
> Oleksandr Andrushchenko (3):
> rangeset: add RANGESETF_no_print flag
> rangeset: add rangeset_reset helper function
> vpci: shrink critical section in vpci_{read/write}
>
> Roger Pau Monne (1):
> vpci: move lock outside of struct vpci
flight 167979 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167979/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167958
test-armhf-armhf-libvirt 16
On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Shrink critical section in vpci_{read/write} as racing calls to
> vpci_{read,write}_hw() shouldn't be a problem. Those are just wrappers
> around pci_conf_{read,write} functions, and the
flight 167980 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167980/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 017564d637e9c3051c2796d1d5b4d5df7179434c
baseline version:
ovmf
Hi, Roger!
On 13.01.22 12:22, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:45PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Take into account guest's BAR view and program its p2m accordingly:
>> gfn is guest's view of the BAR and mfn is the physical BAR
79 matches
Mail list logo
