On 09.12.2021 20:58, Andrew Cooper wrote:
> On 07/12/2021 12:03, Jan Beulich wrote:
>> On 07.12.2021 11:53, Andrew Cooper wrote:
>>> @@ -1243,7 +1196,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>> * data until after we have switched to the relocated
>>> pagetables!
On 09.12.2021 18:34, Andrew Cooper wrote:
> On 07/12/2021 11:37, Jan Beulich wrote:
>> On 07.12.2021 11:53, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1230,7 +1230,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree:
flight 167324 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167319 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167287 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167287/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167229
test-armhf-armhf-libvirt 16
On Tue, 7 Dec 2021, Sergiy Kibrik wrote:
> hi Stefano, Julien,
>
> On 11/10/21 11:12 пп, Stefano Stabellini wrote:
> > On Mon, 8 Nov 2021, Julien Grall wrote:
> [..]
> > > A few years ago, I attempted to disable the swiotlb when Xen configured
> > > the
> > > IOMMU for the device (see [1]). Did
flight 167309 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167309/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Thu, 9 Dec 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The main reason of this change is that unpopulated-alloc
> code cannot be used in its current form on Arm, but there
> is a desire to reuse it to avoid wasting real RAM pages
> for the grant/foreign mappings.
>
>
On Thu, 9 Dec 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Remove the following sentence:
> "This property is unnecessary when booting Dom0 using ACPI."
> for "reg" and "interrupts" properties as the initialization is not
> done via device-tree "hypervisor" node in that
flight 167290 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167290/
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
flight 167306 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167303 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167303/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
flight 167297 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167293 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Thu, 25 Nov 2021, Julien Grall wrote:
> For the record, I actually considered whether it is worth to fully implement
> an M2P on Arm. We technically have space in the struct page_info for that.
> However, I don't see it necessary in other place of Xen, so I would prefer to
> keep the space free
On Thu, Dec 09 2021 at 18:53, Thomas Gleixner wrote:
> On Wed, Dec 08 2021 at 11:58, Jason Gunthorpe wrote:
>> On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
>>> Store the properties which are interesting for various places so the MSI
>>> descriptor fiddling can be removed.
>>>
From: Oleksandr Tyshchenko
Remove the following sentence:
"This property is unnecessary when booting Dom0 using ACPI."
for "reg" and "interrupts" properties as the initialization is not
done via device-tree "hypervisor" node in that case anyway.
Signed-off-by: Oleksandr Tyshchenko
---
flight 167288 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Thu, 9 Dec 2021 at 00:19, Michal Orzel wrote:
>
> Hi Mathieu,
>
> On 08.12.2021 22:23, Mathieu Poirier wrote:
> > On Wed, 8 Dec 2021 at 07:19, Michal Orzel wrote:
> >>
> >> Hi Mathieu,
> >>
> >> On 08.12.2021 01:06, Mathieu Poirier wrote:
> >>> Hi Bertrand,
> >>>
> >>> On Fri, 26 Nov 2021 at
On Wed, Dec 08 2021 at 20:47, Jason Gunthorpe wrote:
> On Mon, Dec 06, 2021 at 11:51:05PM +0100, Thomas Gleixner wrote:
>> +++ b/kernel/irq/msi.c
>> @@ -127,12 +127,37 @@ int msi_setup_device_data(struct device
>> return -ENOMEM;
>>
>> INIT_LIST_HEAD(>list);
>> +
From: Oleksandr Tyshchenko
Xen on Arm has gained new support recently to calculate and report
extended regions (unused address space) safe to use for external
mappings. These regions are reported via "reg" property under
"hypervisor" node in the guest device-tree. As region 0 is reserved
for
From: Oleksandr Tyshchenko
The main reason of this change is that unpopulated-alloc
code cannot be used in its current form on Arm, but there
is a desire to reuse it to avoid wasting real RAM pages
for the grant/foreign mappings.
The problem is that system "iomem_resource" is used for
the
From: Oleksandr Tyshchenko
This patch implements arch_xen_unpopulated_init() on Arm where
the extended regions (if any) are gathered from DT and inserted
into specific Xen resource to be used as unused address space
for Xen scratch pages by unpopulated-alloc code.
The extended region (safe
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:
57f87857dc2de452a796d6bad4f476510efd2aba libxl/arm: Add
From: Oleksandr Tyshchenko
This patch rolls back some of the changes introduced by commit
121f2faca2c0a "xen/balloon: rename alloc/free_xenballooned_pages"
in order to make possible to still allocate xenballooned pages
if CONFIG_XEN_UNPOPULATED_ALLOC is enabled.
On Arm the unpopulated pages
From: Oleksandr Tyshchenko
If memremap_pages() succeeds the range is guaranteed to have proper page
table, there is no need for an additional virt_addr_valid() check.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Boris Ostrovsky
---
Changes RFC -> V2:
- new patch, instead of
"[RFC
From: Oleksandr Tyshchenko
Read the start address of the grant table space from DT
(region 0).
This patch mostly restores behaviour before commit 3cf4095d7446
("arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table")
but trying not to break the ACPI support added after that commit.
So
On 07/12/2021 12:03, Jan Beulich wrote:
> On 07.12.2021 11:53, Andrew Cooper wrote:
>> @@ -1243,7 +1196,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> * data until after we have switched to the relocated
>> pagetables!
>> */
>> barrier();
>>
flight 167285 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167283 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167279 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167275 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On Wed, Dec 08 2021 at 11:58, Jason Gunthorpe wrote:
> On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
>> Store the properties which are interesting for various places so the MSI
>> descriptor fiddling can be removed.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> V2: Use the
On 07/12/2021 11:37, Jan Beulich wrote:
> On 07.12.2021 11:53, Andrew Cooper wrote:
>> This check has existed in one form or another since c/s 369bafdb1c1 "xen: Big
>> changes to x86 start-of-day" in 2007. Even then, AFAICT, it wasn't necessary
>> because there was a clean split between the
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree:
The values are already available in dom->{console,xenstore}_pfn, just like on
the PV side of things. No need to ask Xen.
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/light/libxl_dom.c | 17 +
1 file changed, 5
flight 167271 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167241 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167241/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 167236
Tests which did not succeed,
flight 167267 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
Their calculations of the value to write to the respective command
register can be partly folded, resulting in almost 100 bytes less code
for these two relatively short functions.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@
Let's use the macro in the one place it's supposed to be used, and in
favor of then unnecessary manipulations of the address in
iommu_flush_iotlb_psi(): All leaf functions then already deal correctly
with the supplied address.
There also has never been a need to require (i.e. assert for) the
Let's eliminate the risk of any of these macros getting used with more
complex expressions as arguments.
Where touching lines anyway, also
- switch from u64 to uint64_t,
- drop unnecessary parentheses,
- drop pointless 0x prefixes.
Signed-off-by: Jan Beulich
---
While putting together patch 1, I've noticed two further aspects to
clean up a little.
1: properly parenthesize a number of macros
2: use DMA_TLB_IVA_ADDR()
3: shorten vtd_flush_{context,iotlb}_reg()
Jan
flight 167262 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167262/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On 09/12/2021 14:50, Jan Beulich wrote:
> On 09.12.2021 14:40, Juergen Gross wrote:
>> All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
>> saving and restoring errno in order to not modify it. There is no need
>> to save and restore in those macros, too.
>>
>> Signed-off-by:
On 09.12.2021 14:40, Juergen Gross wrote:
> All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
> saving and restoring errno in order to not modify it. There is no need
> to save and restore in those macros, too.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jan Beulich
> ---
flight 167260 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167260/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
In 4.16 we changed to not build this by default. I think it is now
time to explicitly desupport it, completely, in favour of Linux dm
stub domains.
Signed-off-by: Ian Jackson
---
MAINTAINERS | 2 +-
SUPPORT.md | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff
flight 167258 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
On 08/12/2021 05:22, Sai Kiran Kumar Reddy wrote:
Hi,
Hi,
I have posted my query in xen-users mailing list one week ago. I was not
able to get any response from the community. Could you please look into
it and help me out here? I am trying to install xen(from source code),
on LInux from
All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
saving and restoring errno in order to not modify it. There is no need
to save and restore in those macros, too.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V2:
- style corrections (Jan Beulich)
---
On Thu, Dec 9, 2021 at 8:08 AM Durrant, Paul wrote:
>
> On 09/12/2021 04:58, Jason Andryuk wrote:
> >
> > My attempt at a fix was this:
> > https://lore.kernel.org/xen-devel/20210812005700.3159-1-jandr...@gmail.com/
> >
> > It was in terms of PCI & stubdom startup , but that is the same as PV
> >
On 09.12.21 14:31, Jan Beulich wrote:
On 09.12.2021 13:09, Juergen Gross wrote:
All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
saving and restoring errno in order to not modify it. There is no need
to save and restore in those macros, too.
Signed-off-by: Juergen Gross
On 09.12.2021 13:09, Juergen Gross wrote:
> All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
> saving and restoring errno in order to not modify it. There is no need
> to save and restore in those macros, too.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit
flight 167253 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167253/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
On 09/12/2021 04:58, Jason Andryuk wrote:
My attempt at a fix was this:
https://lore.kernel.org/xen-devel/20210812005700.3159-1-jandr...@gmail.com/
It was in terms of PCI & stubdom startup , but that is the same as PV
hotplug. There were questions about further re-work which went
unanswered,
On 09/12/2021 04:17, Jan Beulich wrote:
Paul,
in 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
reflected in the config") you've moved down the invocation of
libxl__create_pci_backend() from libxl__device_pci_add_xenstore().
In the PV case, soon after the original invocation
Hi,
On Thu, Dec 9, 2021 at 7:18 AM Jan Beulich wrote:
>
> Paul,
>
> in 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
> reflected in the config") you've moved down the invocation of
> libxl__create_pci_backend() from libxl__device_pci_add_xenstore().
> In the PV case, soon after
Paul,
in 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
reflected in the config") you've moved down the invocation of
libxl__create_pci_backend() from libxl__device_pci_add_xenstore().
In the PV case, soon after the original invocation place there is
if (!starting && domtype
All *PRINTF() and *ERROR() macros are based on xc_reportv() which is
saving and restoring errno in order to not modify it. There is no need
to save and restore in those macros, too.
Signed-off-by: Juergen Gross
---
tools/libs/ctrl/xc_private.h | 32 +++-
1 file
flight 167247 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
For guests in shadow mode the P2M table gets used only by software. The
only place where it matters whether superpages in the P2M can be dealt
with is sh_unshadow_for_p2m_change(). That function has been capabale of
handling them even before commit 0ca1669871f8a ("P2M: check whether hap
mode is
In preparation for reactivating the presently dead 2M page path of the
function,
- also deal with the case of replacing an L1 page table all in one go,
- pull common checks out of the switch(). This includes extending a
_PAGE_PRESENT check to L1 as well, which presumably was deemed
redundant
I did notice this anomaly in the context of IOMMU side work.
1: shadow: slightly consolidate sh_unshadow_for_p2m_change()
2: P2M: allow 2M superpage use for shadowed guests
Jan
On 09.12.2021 10:47, Juergen Gross wrote:
> On 09.12.21 09:48, Jan Beulich wrote:
>> On 09.12.2021 08:09, Juergen Gross wrote:
>>> Today RING_HAS_UNCONSUMED_*() macros are returning the number of
>>> unconsumed requests or responses instead of a boolean as the name of
>>> the macros would imply.
On 09.12.2021 11:41, Juergen Gross wrote:
> On 09.12.21 11:36, Juergen Gross wrote:
>> On 09.12.21 11:26, Jan Beulich wrote:
>>> do_memory_op() supplies return value and has errno set the usual way.
>>> Don't overwrite errno with 1 (aka EPERM on at least Linux).
>>>
>>> Signed-off-by: Jan Beulich
On Wed, Dec 08, 2021 at 08:07:55AM +0100, Jan Beulich wrote:
> As was briefly discussed on the December Community Call, I'd like to
> propose to widen Anthony's maintainership to all of tools/. This then
> means that the special LIBXENLIGHT entry can go away.
>
> Signed-off-by: Jan Beulich
On 09.12.21 11:36, Juergen Gross wrote:
On 09.12.21 11:26, Jan Beulich wrote:
do_memory_op() supplies return value and has errno set the usual way.
Don't overwrite errno with 1 (aka EPERM on at least Linux).
Signed-off-by: Jan Beulich
---
An alternative would be to let go of the DPRINTK() and
On 09.12.21 11:26, Jan Beulich wrote:
do_memory_op() supplies return value and has errno set the usual way.
Don't overwrite errno with 1 (aka EPERM on at least Linux).
Signed-off-by: Jan Beulich
---
An alternative would be to let go of the DPRINTK() and leave errno and
err alone altogether.
flight 167242 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
do_memory_op() supplies return value and has errno set the usual way.
Don't overwrite errno with 1 (aka EPERM on at least Linux).
Signed-off-by: Jan Beulich
---
An alternative would be to let go of the DPRINTK() and leave errno and
err alone altogether. While the hypervisor side of the hypercall
Hi Oleksandr,
> On 9 Dec 2021, at 7:29 am, 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 on
> Domain-0 to perform the initialization of
Hi Oleksandr,
> On 9 Dec 2021, at 7:29 am, 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 an IO trap handler for the emulated
> PCI host bridge we are not breaking
Hi Oleksandr,
> On 9 Dec 2021, at 7:29 am, 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 and
> COMMAND registers require emulation for guests
On Tue, Dec 07, 2021 at 01:23:30PM +, Stefan Hajnoczi wrote:
v3:
- Fixed FUSE export aio_set_fd_handler() call that I missed and double-checked
for any other missing call sites using Coccinelle [Rich]
v2:
- Cleaned up unused return values in nvme and virtio-blk [Stefano]
- Documented
On 01.12.2021 12:20, Jan Beulich wrote:
> @@ -333,6 +334,9 @@ p2m_pod_set_mem_target(struct domain *d,
> int ret = 0;
> unsigned long populated, pod_target;
>
> +if ( has_arch_pdevs(d) || cache_flush_permitted(d) )
> +return -ENOTEMPTY;
This breaks toolstack based
On 09.12.21 09:48, Jan Beulich wrote:
On 09.12.2021 08:09, Juergen Gross wrote:
Today RING_HAS_UNCONSUMED_*() macros are returning the number of
unconsumed requests or responses instead of a boolean as the name of
the macros would imply.
As this "feature" is already being used, rename the
On 09.12.21 10:05, Jan Beulich wrote:
On 08.12.2021 16:55, Juergen Gross wrote:
In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall handler calls via the function array
by
> On 30 Nov 2021, at 18:11, Jan Beulich wrote:
>
> CAUTION: This email originated from outside of our organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> Signed-off-by: Jan Beulich
Reviewed by: Alexandru Isaila
>
>
On 08.12.2021 16:55, Juergen Gross wrote:
> In order to avoid indirect function calls on the hypercall path as
> much as possible this series is removing the hypercall function tables
> and is replacing the hypercall handler calls via the function array
> by automatically generated call macros.
>
flight 167240 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 167239
build-i386-xsm
flight 167236 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167236/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167234
test-armhf-armhf-libvirt 16
On 08.12.2021 16:55, Juergen Gross wrote:
> The definition of compat_platform_op_t is in compat/platform.h
> already, so include that file from hypercall.h instead of repeating
> the typedef.
>
> This allows to remove the related include statement from
> arch/x86/x86_64/platform_hypercall.c.
>
>
On 30.11.2021 17:11, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
May I ask for an ack (or otherwise) here please?
Thanks, Jan
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -263,7 +263,7 @@ int arch_monitor_domctl_event(struct dom
> if ( unlikely(old_status ==
On 09.12.2021 08:09, Juergen Gross wrote:
> Today RING_HAS_UNCONSUMED_*() macros are returning the number of
> unconsumed requests or responses instead of a boolean as the name of
> the macros would imply.
>
> As this "feature" is already being used, rename the macros to
> RING_NR_UNCONSUMED_*()
flight 167238 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167238/
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
flight 167239 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c82ab4d8c148c4009e0b31d1dd2ea6f7d4aea80d
baseline version:
ovmf
92 matches
Mail list logo
