On 14.11.2022 16:04, Carlo Nonato wrote:
> On Thu, Nov 10, 2022 at 5:47 PM Jan Beulich wrote:
>> On 22.10.2022 17:51, Carlo Nonato wrote:
>>> --- a/xen/arch/arm/p2m.c
>>> +++ b/xen/arch/arm/p2m.c
>>> @@ -661,7 +661,12 @@ static int p2m_create_table(struct p2m_domain *p2m,
>>> lpae_t *entry)
>>>
>
d9721f19cd
Author: Stefan Hajnoczi
Date: Mon Nov 14 13:31:17 2022 -0500
Merge tag 'pull-target-arm-20221114' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging
target-arm queue:
* hw/intc/arm_gicv3: fix prio masking on pmr write
* MAINTAINE
Hello,
Reading this patch, I found one place that can be improved.
On 11/15/22 03:52, Penny Zheng wrote:
> Instead of using multiple function parameters to deliver various shm-related
> info, like host physical address, SHMID, etc, and with the introduction
> of new struct "shm_membank", we could
Hi Ayan,
> > +
> > +#endif /* __ASM_ARM_PLATFORMS_FVP_BASER_H__ */
> > diff --git a/xen/arch/arm/platforms/Kconfig
> b/xen/arch/arm/platforms/Kconfig
> > index c93a6b2756..0904793a0b 100644
> > --- a/xen/arch/arm/platforms/Kconfig
> > +++ b/xen/arch/arm/platforms/Kconfig
> > @@ -1,6 +1,7 @@
> >
flight 174770 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
flight 174769 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174769/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174762
test-amd64-i386-xl-qemuu-win7-amd64
After patching previous commits, we could make feature of "static shared memory"
supported in SUPPORT.md.
Signed-off-by: Penny Zheng
---
SUPPORT.md | 2 +-
xen/arch/arm/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index ab71464c
When host address is not provided in "xen,shared-mem" property, shared
memory region is allocated from heap by Xen. It is normally not
contiguous and consisted of multiple memory blocks.
Under above scenario, when "xen,offset" is also offered, we need to find at
which memory block the offset locate
When host address is provided in "xen,shared-mem" property([pbase,
gbase, psize]), it is easy to decide where to map to the borrower
domain if "xen,offset" is also provided.
The partially-shared region shall be starting at pbase + offset, and
ending at pbase + size.
Signed-off-by: Penny Zheng
---
This commit amends docs(booting.txt) to include the new scenario where host
address is not provided in "xen,shared-mem" property, and we also add a new
example to explain in details.
We also fix some buggy info in the docs, like SHMID is "my-shared-mem-1",
not "0x1".
Signed-off-by: Penny Zheng
-
We introduce "xen,offset" to handle the case where memory from the owner is
shared with multiple borrowers. Each borrower would have its own offset within
the region shared by the owner.
Add relative check when parsing static shared memory node, to make sure
that "xen,offset" could be only provide
We use paddr_assigned to indicate whether host address is provided, by
checking the length of "xen,shared-mem" property.
And the shm matching criteria shall also be adapt to the new scenario, by
adding when host address is not provided, if SHMID matches, the region size
must exactly match too.
Al
With the introduction of new scenario where host address is not provided
in "xen,shared-mem", the function "map_regions_p2mt" for setting up
P2M foreign mapping for borrower domain shall be adapted to it too.
Here we implement a new helper "borrower_physmap_add_memory" to
cover both scenarios.
Si
With the introduction of new scenario where host address is not provided
in "xen,shared-mem", the function "assign_shared_memory" shall be adapted
to it too.
Shared memory will already be allocated from heap, when calling
"assign_shared_memory" with unprovided host address.
So in "assign_shared_me
when host address is not provided in "xen,shared-mem", we let Xen
allocate requested shared memory from heap, and once the shared memory is
allocated, it will be marked as static(PGC_static), which means that it will be
reserved as static memory, and will not go back to heap even on freeing.
Signe
When host address is not provided in "xen,shared-mem", we let Xen
automatically allocate requested static shared memory from heap, and it
stands good chance of having multiple host memory banks allocated for the
requested static shared memory as a result. Therefore current membank is not
going to c
This commit re-arranges the static shared memory regions into a separate array
shm_meminfo. And static shared memory region now would have its own structure
'shm_membank' to hold all shm-related members, like shm_id, etc, and a pointer
to the normal memory bank 'membank'. This will avoid continuing
We split the codes of allocate_bank_memory into two parts,
allocate_domheap_memory and guest_physmap_memory.
One is about allocating guest RAM from heap, which could be re-used later for
allocating static shared memory from heap when host address is not provided.
The other is building up guest P2
Instead of using multiple function parameters to deliver various shm-related
info, like host physical address, SHMID, etc, and with the introduction
of new struct "shm_membank", we could switch to use "shm_membank" as
function parameter to replace them all, to make codes more clear and
tidy.
Signe
There are some unsolving issues on current 4.17 static shared memory
feature[1], including:
- In order to avoid keeping growing 'membank', having the shared memory
regions in a separate array is preferred. And shared memory region should
have its own structure which would contain a pointer/index to
Hi Roger,
> -Original Message-
> Subject: RE: [PATCH 2/3] CHANGELOG: Add missing entries for work during
> the 4.17 release
>
> Hi Jan,
>
> > -Original Message-
> > On 11.11.2022 14:58, Henry Wang wrote:
> > > Another question for adding another entry for x86 that worth to
> > >
I was really hoping to avoid this, but its now too late in the 4.17 freeze and
we still don't have working fixes.
The in-Xen calculations for assistance capabilities are buggy. For the
avoidance of doubt, the original intention was to be able to control every
aspect of a APIC acceleration so we c
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Subject: [PATCH for-4.17] Introduce CC-BY-4.0 license under LICENSES/
>
> We use CC-BY-4.0 for many of the documents under docs/ so we should
> have
> a copy of the license.
>
> Signed-off-by: Stefano Stabellini
Per the mes
On Mon, Nov 14, 2022 at 07:39:48PM +, Andrew Cooper wrote:
> On 14/11/2022 19:20, Marek Marczykowski-Górecki wrote:
> > The /dev/mem is used for two purposes:
> > - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
> > - reading Pending Bit Array (PBA)
> >
> > The first one was originally done because when
We use CC-BY-4.0 for many of the documents under docs/ so we should have
a copy of the license.
Signed-off-by: Stefano Stabellini
---
LICENSES/CC-BY-4.0 | 410 +
1 file changed, 410 insertions(+)
create mode 100644 LICENSES/CC-BY-4.0
diff --git a/LIC
flight 174767 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174767/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174695
test-amd64-amd64-xl-qemuu-win7-a
On Mon, 14 Nov 2022, Juergen Gross wrote:
> Instead of "0x01" use the HVM_PARAM_CALLBACK_TYPE_PCI_INTX define from
> the interface header in get_callback_via().
>
> Signed-off-by: Juergen Gross
Acked-by: Stefano Stabellini
> ---
> drivers/xen/platform-pci.c | 3 ++-
> 1 file changed, 2 inser
... now that we a link available.
Fixes: 9deaf2d932f0 ("x86/spec-ctrl: Enable Zen2 chickenbit")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Henry Wang
For 4.17(?) Seeing if I can sneak it in as just a documentation change,
seeing as there are others
On 03/11/2022 17:02, Roger Pau Monne wrote:
> The current logic for AMD SSBD context switches it on every
> vm{entry,exit} if the Xen and guest selections don't match. This is
> expensive when not using SPEC_CTRL, and hence should be avoided as
> much as possible.
>
> When SSBD is not being set fr
On 14/11/2022 19:20, Marek Marczykowski-Górecki wrote:
> The /dev/mem is used for two purposes:
> - reading PCI_MSIX_ENTRY_CTRL_MASKBIT
> - reading Pending Bit Array (PBA)
>
> The first one was originally done because when Xen did not send all
> vector ctrl writes to the device model, so QEMU mig
Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
on the same page as MSI-X table. Device model (especially one in
stubdomain) cannot really handle those, as direct writes to that page is
refused (page is on mmio_ro_ranges list). Instead, add internal ioreq
server that handle
QEMU needs to know whether clearing maskbit of a vector is really
clearing, or was already cleared before. Currently Xen sends only
clearing that bit to the device model, but not setting it, so QEMU
cannot detect it. Because of that, QEMU is working this around by
checking via /dev/mem, but that is
The /dev/mem is used for two purposes:
- reading PCI_MSIX_ENTRY_CTRL_MASKBIT
- reading Pending Bit Array (PBA)
The first one was originally done because when Xen did not send all
vector ctrl writes to the device model, so QEMU might have outdated old
register value. This has been changed in Xen,
Call pci_default_write_config() in xen_pt_pci_write_config() only for
registers that do not have custom handler, and do that only after
resolving them. This is important for two reasons:
1. XenPTRegInfo has ro_mask which needs to be enforced - Xen-specific
hooks do that on their own (especially
flight 174765 linux-5.4 real [real]
flight 174771 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174765/
http://logs.test-lab.xenproject.org/osstest/logs/174771/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
From: Mika Westerberg
Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.
While at it drop doubled empty line before pdev_sort_resources().
No functional changes intended.
Sugge
Provide two new helper macros to iterate over PCI device resources and
convert users.
Looking at it, refactor existing pci_bus_for_each_resource() and convert
users accordingly.
This applies on top of this patch Mika sent out earlier:
https://lore.kernel.org/r/20221114115953.40236-1-mika.westerb.
The pci_bus_for_each_resource_p() hides the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
---
drivers/eisa/pci_eisa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/eisa/
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
---
.clang-format | 1 +
d
The pci_bus_for_each_resource_p() hides the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Acked-by: Dominik Brodowski
---
drivers/pcmcia/rsrc_nonstatic.c | 9 +++--
drivers/pcmcia/yenta_socket.c |
Hi Wei,
On 04/11/2022 10:07, Wei Chen wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
On Armv8-A, Xen has a fixed virtual start address (link address
too) for al
On 11/14/22 10:56, Anthony PERARD wrote:
On Mon, Nov 14, 2022 at 08:53:17AM -0700, Jim Fehlig wrote:
On 11/14/22 01:18, Jan Beulich wrote:
On 14.11.2022 07:43, Henry Wang wrote:
Sorry, missed Anthony (The toolstack maintainer). Also added him
to this thread.
Indeed there's nothing x86-ish in
On Mon, Nov 14, 2022 at 08:53:17AM -0700, Jim Fehlig wrote:
> On 11/14/22 01:18, Jan Beulich wrote:
> > On 14.11.2022 07:43, Henry Wang wrote:
> > > Sorry, missed Anthony (The toolstack maintainer). Also added him
> > > to this thread.
> >
> > Indeed there's nothing x86-ish in here, it's all about
On Mon, Nov 14, 2022 at 12:30:39PM +, Luca Fancellu wrote:
> The cppcheck workflow instead is:
>
> 1) call analysis-parse-tags-cppcheck
> 2) generate cppcheck suppression list
> 3) build Xen (and run cppcheck on built source files)
> 4) collect and generate report
> 5) call analysis-clean
>
>
On Mon, Nov 07, 2022 at 10:47:36AM +, Luca Fancellu wrote:
> xen/Makefile| 50 ++-
Hi Luca,
Could you write a shell script which would probably be easier to
read/modify than this rather complicated looking set of Makefile rules?
As I see it, a potential `anal
On 14.11.2022 13:30, Luca Fancellu wrote:
>> On 14 Nov 2022, at 07:30, Jan Beulich wrote:
>> On 11.11.2022 21:52, Stefano Stabellini wrote:
>>> On Fri, 11 Nov 2022, Jan Beulich wrote:
Did you consider the alternative approach of copying the tree, altering
it (while or after copying), run
On Mon, Nov 14, 2022 at 03:31:39PM +, Andrew Cooper wrote:
> On 14/11/2022 13:15, Roger Pau Monne wrote:
> > On Fri, Nov 11, 2022 at 05:47:02PM +, Andrew Cooper wrote:
> >> On 11/11/2022 17:35, Andrew Cooper wrote:
> >>> On 11/11/2022 07:45, Jan Beulich wrote:
> On 10.11.2022 23:47, An
On 11/14/22 01:18, Jan Beulich wrote:
On 14.11.2022 07:43, Henry Wang wrote:
Sorry, missed Anthony (The toolstack maintainer). Also added him
to this thread.
Indeed there's nothing x86-ish in here, it's all about data representation.
It merely happens to be (for now) x86-specific data which is
On 14/11/2022 13:15, Roger Pau Monne wrote:
> On Fri, Nov 11, 2022 at 05:47:02PM +, Andrew Cooper wrote:
>> On 11/11/2022 17:35, Andrew Cooper wrote:
>>> On 11/11/2022 07:45, Jan Beulich wrote:
On 10.11.2022 23:47, Andrew Cooper wrote:
> On 04/11/2022 16:18, Roger Pau Monne wrote:
flight 174764 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462
test-armhf-armhf-xl
Hi Jan,
On Thu, Nov 10, 2022 at 5:47 PM Jan Beulich wrote:
>
> On 22.10.2022 17:51, Carlo Nonato wrote:
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -661,7 +661,12 @@ static int p2m_create_table(struct p2m_domain *p2m,
> > lpae_t *entry)
> >
> > ASSERT(!p2m_is_valid(*ent
Instead of "0x01" use the HVM_PARAM_CALLBACK_TYPE_PCI_INTX define from
the interface header in get_callback_via().
Signed-off-by: Juergen Gross
---
drivers/xen/platform-pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-p
flight 174766 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174766/
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 1
On Fri, Nov 11, 2022 at 05:47:02PM +, Andrew Cooper wrote:
> On 11/11/2022 17:35, Andrew Cooper wrote:
> > On 11/11/2022 07:45, Jan Beulich wrote:
> >> On 10.11.2022 23:47, Andrew Cooper wrote:
> >>> On 04/11/2022 16:18, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
>
> On 14 Nov 2022, at 07:30, Jan Beulich wrote:
>
> On 11.11.2022 21:52, Stefano Stabellini wrote:
>> On Fri, 11 Nov 2022, Jan Beulich wrote:
>>> On 11.11.2022 11:42, Luca Fancellu wrote:
> On 9 Nov 2022, at 10:36, Jan Beulich wrote:
> On 09.11.2022 11:08, Luca Fancellu wrote:
On Thu, Nov 10, 2022 at 10:47:07PM +, Andrew Cooper wrote:
> On 04/11/2022 16:18, Roger Pau Monne wrote:
> > The current reporting of the hardware assisted APIC options is done by
> > checking "virtualize APIC accesses" which is not very helpful, as that
> > feature doesn't avoid a vmexit, inst
From: Andi Kleen
Symbols referenced from assembler (either directly or e.f. from
DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because
they could end up in a different object file than the assembler. This
can lead to linker errors without this patch.
So mark xen_vcpu_stolen() as
free_irq() is missing in case of error in platform_pci_probe(), fix that.
Signed-off-by: ruanjinjie
Reviewed-by: Oleksandr Tyshchenko
---
v2:
- improve the subject to describe which subsystem it targets.
---
drivers/xen/platform-pci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
On 2022/11/14 18:45, Oleksandr Tyshchenko wrote:
>
> On 14.11.22 09:07, ruanjinjie wrote:
>
> Hello
>
>
>> free_irq() is missing in case of error, fix that.
>>
>> Signed-off-by: ruanjinjie
>
>
> Nit: neither subject nor description mentions which subsystem current
> patch targets.
>
> I
flight 174762 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174762/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl 22 guest-start/debian.repeat fail in 174753 pass in 174762
test-amd64-i386-qemuu-rhel6hvm-a
On 14.11.2022 11:31, Marek Marczykowski-Górecki wrote:
> When Xen domain configures MSI-X, the usual approach is to enable MSI-X
> together with masking all of them via the config space, then fill the
> table and only then clear PCI_MSIX_FLAGS_MASKALL. Allow doing this via
> QEMU running in a stub
On 14.11.22 09:07, ruanjinjie wrote:
Hello
> free_irq() is missing in case of error, fix that.
>
> Signed-off-by: ruanjinjie
Nit: neither subject nor description mentions which subsystem current
patch targets.
I would add "xen-platform:" or "xen/platform-pci:" at least.
Reviewed-by: Olek
When Xen domain configures MSI-X, the usual approach is to enable MSI-X
together with masking all of them via the config space, then fill the
table and only then clear PCI_MSIX_FLAGS_MASKALL. Allow doing this via
QEMU running in a stub domain.
Previously, when changing PCI_MSIX_FLAGS_MASKALL was n
On 11.11.2022 15:41, David Vrabel wrote:
> On 11/11/2022 09:44, Jan Beulich wrote:
>>
>> The idea of the WARN() / BUG_ON() is to
>> - not leave failed unmasking unrecorded,
>> - not continue after failure to mask an entry.
>
> Then lets make msi_set_mask_bit() unable to fail with something like
>
On 14.11.2022 10:37, Wei Chen wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年11月14日 17:29
>> To: Wei Chen
>> Cc: nd ; Andrew Cooper ; Roger Pau
>> Monné ; Wei Liu ; George Dunlap
>> ; Julien Grall ; Stefano
>> Stabellini ; xen-devel@lists.xenproject.org
>> Su
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年11月14日 17:29
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v8 0/6] Device tree based NUMA s
On 12.11.2022 14:23, Juergen Gross wrote:
> Calling xen_set_upcall_vector() before the local APIC has been
> initialized results in warnings when setting up the local APIC:
>
> [0.037322] APIC: Stale IRR: 0008, ...
>
> Avoid this problem by moving the call of xen_set_upcall_vector() for
>
On 14.11.2022 09:33, Wei Chen wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年11月14日 16:23
>> To: Wei Chen
>> Cc: nd ; Andrew Cooper ; Roger Pau
>> Monné ; Wei Liu ; George Dunlap
>> ; Julien Grall ; Stefano
>> Stabellini ; xen-devel@lists.xenproject.org
>> Su
(shrinking Cc list to just xen-devel@)
On 11.11.2022 15:50, Juergen Gross wrote:
> On 11.11.22 14:17, Jan Beulich wrote:
>> On 11.11.2022 13:44, Juergen Gross wrote:
>>> On 11.11.22 10:01, Juergen Gross wrote:
Writing a patch now ...
>>>
>>> For the APs this is working as expected.
>>>
>>> Th
flight 174761 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174761/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 8 xen-boot fail in 174756 pass in 174761
test-amd64-amd64-xl-qcow2 21 gu
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年11月14日 16:23
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v8 0/6] Device tree based NUMA s
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: vnuma_nodes missing pnode 0
>
> On 14.11.2022 07:43, Henry Wang wrote:
> > Sorry, missed Anthony (The toolstack maintainer). Also added him
> > to this thread.
>
> Indeed there's nothing x86-ish in here, it's all about data
On 14.11.2022 09:14, Wei Chen wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年11月14日 16:05
>> To: Wei Chen
>> Cc: nd ; Andrew Cooper ; Roger Pau
>> Monné ; Wei Liu ; George Dunlap
>> ; Julien Grall ; Stefano
>> Stabellini ; xen-devel@lists.xenproject.org
>> Su
On 14.11.2022 07:43, Henry Wang wrote:
> Sorry, missed Anthony (The toolstack maintainer). Also added him
> to this thread.
Indeed there's nothing x86-ish in here, it's all about data representation.
It merely happens to be (for now) x86-specific data which is being dealt
with.
Internally I indic
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年11月14日 16:05
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v8 0/6] Device tree based NUMA s
On 14.11.2022 07:34, Wei Chen wrote:
> (The Arm device tree based NUMA support patch set contains 35
> patches. In order to make stuff easier for reviewers, I split
> them into 3 parts:
> 1. Preparation. I have re-sorted the patch series. And moved
>independent patches to the head of the series
flight 174763 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174763/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0cb30c3f5e9b2be5157224afdf75fa16bc09b9c7
baseline version:
ovmf b9e702c3c9bfe7bfb6bbc
77 matches
Mail list logo
