Re: [PATCH v3 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
On 21.05.2021 08:33, Michal Orzel wrote:
> On 17.05.2021 18:03, Julien Grall wrote:
>> On 17/05/2021 08:01, Jan Beulich wrote:
>>> On 12.05.2021 19:59, Julien Grall wrote:
Hi,
On 11/05/2021 07:37, Michal Orzel wrote:
> On 05.05.2021 10:00, Jan Beulich wrote:
>> On 05.05.2021 09:43, Michal Orzel wrote:
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
>>> /* Return address and mode */
>>> __DECL_REG(pc64, pc32); /* ELR_EL2 */
>>> - uint32_t cpsr; /* SPSR_EL2 */
>>> + uint64_t cpsr; /* SPSR_EL2 */
>>> union {
>>> - uint32_t spsr_el1; /* AArch64 */
>>> + uint64_t spsr_el1; /* AArch64 */
>>> uint32_t spsr_svc; /* AArch32 */
>>> };
>>
>> This change affects, besides domctl, also default_initialise_vcpu(),
>> which Arm's arch_initialise_vcpu() calls. I realize do_arm_vcpu_op()
>> only allows two unrelated VCPUOP_* to pass, but then I don't
>> understand why arch_initialise_vcpu() doesn't simply return e.g.
>> -EOPNOTSUPP. Hence I suspect I'm missing something.
I think it is just an overlooked when reviewing the following commit:
commit 192df6f9122ddebc21d0a632c10da3453aeee1c2
Author: Roger Pau Monné
Date: Tue Dec 15 14:12:32 2015 +0100
x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from
HVM
guests.
This patch introduces a new structure (vcpu_hvm_context) that
should be used
in conjuction with the VCPUOP_initialise hypercall in order to
initialize
vCPUs for HVM guests.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Acked-by: Ian Campbell
On Arm, the structure vcpu_guest_context is not exposed outside of Xen
and the tools. Interestingly vcpu_guest_core_regs is but it should only
be used within vcpu_guest_context.
So as this is not used by stable ABI, it is fine to break it.
>>
> I agree that do_arm_vcpu_op only allows two VCPUOP* to pass and
> arch_initialise_vcpu being called in case of VCPUOP_initialise
> has no sense as VCPUOP_initialise is not supported on arm.
> It makes sense that it should return -EOPNOTSUPP.
> However do_arm_vcpu_op will not accept VCPUOP_initialise and will return
> -EINVAL. So arch_initialise_vcpu for arm will not be called.
> Do you think that changing this behaviour so that arch_initialise_vcpu
> returns
> -EOPNOTSUPP should be part of this patch?
I think this change is unrelated. So it should be handled in a follow-up
patch.
>>>
>>> My only difference in viewing this is that I'd say the adjustment
>>> would better be a prereq patch to this one, such that the one here
>>> ends up being more obviously correct.
>>
>> The function is already not reachable so I felt it was unfair to require the
>> clean-up for merging this code.
>>
>>> Also, if the function is
>>> indeed not meant to be reachable, besides making it return
>>> -EOPNOTSUPP (or alike) it should probably also have
>>> ASSERT_UNREACHABLE() added.
>>
>> +1 on the idea.
>>
>> Cheers,
>>
> FWICS, all the discussion is about creating the next patch fixing the
> VCPUOP_initialise function.
> Is there anything left to do in this patch or are you going to ack it?
Afaic I'd find it quite helpful if that other patch was a prereq to this
one, making more obvious that the change here is not going to break
anything. But it's Arm stuff, so Arm folks get the final say anyway.
Jan
Re: [PATCH 07/10] xen/arm: intruduce alloc_domstatic_pages
On 21.05.2021 08:41, Penny Zheng wrote:
> Hi Jan
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, May 18, 2021 7:23 PM
>> To: Penny Zheng
>> Cc: Bertrand Marquis ; Wei Chen
>> ; nd ; xen-devel@lists.xenproject.org;
>> sstabell...@kernel.org; jul...@xen.org
>> Subject: Re: [PATCH 07/10] xen/arm: intruduce alloc_domstatic_pages
>>
>> On 18.05.2021 10:57, Penny Zheng wrote:
From: Jan Beulich
Sent: Tuesday, May 18, 2021 3:35 PM
On 18.05.2021 07:21, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2447,6 +2447,9 @@ int assign_pages(
> {
> ASSERT(page_get_owner(&pg[i]) == NULL);
> page_set_owner(&pg[i], d);
> +/* use page_set_reserved_owner to set its reserved domain owner.
*/
> +if ( (pg[i].count_info & PGC_reserved) )
> +page_set_reserved_owner(&pg[i], d);
Now this is puzzling: What's the point of setting two owner fields to
the same value? I also don't recall you having introduced
page_set_reserved_owner() for x86, so how is this going to build there?
>>>
>>> Thanks for pointing out that it will fail on x86.
>>> As for the same value, sure, I shall change it to domid_t domid to record
>>> its
>> reserved owner.
>>> Only domid is enough for differentiate.
>>> And even when domain get rebooted, struct domain may be destroyed, but
>>> domid will stays The same.
>>
>> Will it? Are you intending to put in place restrictions that make it
>> impossible
>> for the ID to get re-used by another domain?
>>
>>> Major user cases for domain on static allocation are referring to the
>>> whole system are static, No runtime creation.
>>
>> Right, but that's not currently enforced afaics. If you would enforce it, it
>> may
>> simplify a number of things.
>>
> @@ -2509,6 +2512,56 @@ struct page_info *alloc_domheap_pages(
> return pg;
> }
>
> +/*
> + * Allocate nr_pfns contiguous pages, starting at #start, of static
> +memory,
> + * then assign them to one specific domain #d.
> + * It is the equivalent of alloc_domheap_pages for static memory.
> + */
> +struct page_info *alloc_domstatic_pages(
> +struct domain *d, unsigned long nr_pfns, paddr_t start,
> +unsigned int memflags)
> +{
> +struct page_info *pg = NULL;
> +unsigned long dma_size;
> +
> +ASSERT(!in_irq());
> +
> +if ( memflags & MEMF_no_owner )
> +memflags |= MEMF_no_refcount;
> +
> +if ( !dma_bitsize )
> +memflags &= ~MEMF_no_dma;
> +else
> +{
> +dma_size = 1ul << bits_to_zone(dma_bitsize);
> +/* Starting address shall meet the DMA limitation. */
> +if ( dma_size && start < dma_size )
> +return NULL;
It is the entire range (i.e. in particular the last byte) which needs
to meet such a restriction. I'm not convinced though that DMA width
restrictions and static allocation are sensible to coexist.
>>>
>>> FWIT, if starting address meets the limitation, the last byte, greater
>>> than starting address shall meet it too.
>>
>> I'm afraid I don't know what you're meaning to tell me here.
>>
>
> Referring to alloc_domheap_pages, if `dma_bitsize` is none-zero value,
> it will use alloc_heap_pages to allocate pages from [dma_zone + 1,
> zone_hi], `dma_zone + 1` pointing to address larger than 2^(dma_zone + 1).
> So I was setting address limitation for the starting address.
But does this zone concept apply to static pages at all?
Jan
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 20.05.21 14:08, Jan Beulich wrote: On 20.05.2021 13:57, Juergen Gross wrote: On 20.05.21 13:42, Jan Beulich wrote: xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. Reported-by: Olaf Hering Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Thanks. I guess I forgot Cc: sta...@vger.kernel.org If you agree, can you please add this before pushing to Linus? Uh, just had a look why x86_configure_nx() was called after xen_setup_gdt(). Upstream your patch will be fine, but before kernel 5.9 it will break running as 32-bit PV guest (see commit 36104cb9012a82e7). So I will take your patch as is, but for kernels 5.8 and older I recommend a different approach by directly setting the NX capability after checking the cpuid bit instead of letting that do get_cpu_cap(). Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 21.05.2021 09:18, Juergen Gross wrote: > On 20.05.21 14:08, Jan Beulich wrote: >> On 20.05.2021 13:57, Juergen Gross wrote: >>> On 20.05.21 13:42, Jan Beulich wrote: xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. Reported-by: Olaf Hering Signed-off-by: Jan Beulich >>> >>> Reviewed-by: Juergen Gross >> >> Thanks. I guess I forgot >> >> Cc: sta...@vger.kernel.org >> >> If you agree, can you please add this before pushing to Linus? > > Uh, just had a look why x86_configure_nx() was called after > xen_setup_gdt(). > > Upstream your patch will be fine, but before kernel 5.9 it will > break running as 32-bit PV guest (see commit 36104cb9012a82e7). Oh, indeed. That commit then actually introduced the issue here, and hence a Fixes: tag may be warranted. > So I will take your patch as is, but for kernels 5.8 and older I > recommend a different approach by directly setting the NX > capability after checking the cpuid bit instead of letting that > do get_cpu_cap(). Right - perhaps the only halfway viable option. 64-bit kernels predating 4f277295e54c may then also need that one, but perhaps all stable ones already have it because it was tagged for stable. Jan
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 21.05.21 09:26, Jan Beulich wrote: On 21.05.2021 09:18, Juergen Gross wrote: On 20.05.21 14:08, Jan Beulich wrote: On 20.05.2021 13:57, Juergen Gross wrote: On 20.05.21 13:42, Jan Beulich wrote: xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. Reported-by: Olaf Hering Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Thanks. I guess I forgot Cc: sta...@vger.kernel.org If you agree, can you please add this before pushing to Linus? Uh, just had a look why x86_configure_nx() was called after xen_setup_gdt(). Upstream your patch will be fine, but before kernel 5.9 it will break running as 32-bit PV guest (see commit 36104cb9012a82e7). Oh, indeed. That commit then actually introduced the issue here, and hence a Fixes: tag may be warranted. Added it already. :-) And I've limited the backport to happen not for 5.8 and older, of course. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[libvirt test] 162110: regressions - FAIL
flight 162110 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/162110/ 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 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt 015fe0439f0592ca0b0274b306258a1e7aafe43c baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 315 days Failing since151818 2020-07-11 04:18:52 Z 314 days 307 attempts Testing same since 162110 2021-05-21 04:20:08 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle SeongHyun Jo Shalini Chellathurai Saroja Shaojun Yang Shi Lei simmon Simon Gaiser Stefan Bader Stefan Berger Stefan Berger Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Ville Skyttä Wang Xin WangJian Weblate Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yaroslav Kargin Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
Re: [PATCH v2 0/2] xen-pciback: a fix and a workaround
On 18.05.21 18:12, Jan Beulich wrote: The first change completes a several years old but still incomplete change. As mentioned there, reverting the original change may also be an option. The second change works around some odd libxl behavior, as described in [1]. As per a response to that mail addressing the issue in libxl may also be possible, but it's not clear to me who would get to doing so at which point in time. Hence the kernel side alternative is being proposed here. As to Konrad being on the Cc list: I find it puzzling that he's listed under "XEN PCI SUBSYSTEM", but pciback isn't considered part of this. 1: redo VF placement in the virtual topology 2: reconfigure also from backend watch handler Series pushed to xen/tip.git for-linus-5.13b Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 20.05.21 13:42, Jan Beulich wrote: xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. For this to work when NX is not available, x86_configure_nx() needs to be called first. Reported-by: Olaf Hering Signed-off-by: Jan Beulich Pushed to xen/tip.git for-linus-5.13b Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Goes through all the drivers and deletes the default hook since it's
the default now.
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes"
Cc: Linus Walleij
Cc: Emma Anholt
Cc: David Lechner
Cc: Kamlesh Gurudasani
Cc: Oleksandr Andrushchenko
Cc: Daniel Vetter
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: Andy Shevchenko
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 -
drivers/gpu/drm/gud/gud_drv.c| 1 -
drivers/gpu/drm/mcde/mcde_display.c | 1 -
drivers/gpu/drm/pl111/pl111_display.c| 1 -
drivers/gpu/drm/tiny/hx8357d.c | 1 -
drivers/gpu/drm/tiny/ili9225.c | 1 -
drivers/gpu/drm/tiny/ili9341.c | 1 -
drivers/gpu/drm/tiny/ili9486.c | 1 -
drivers/gpu/drm/tiny/mi0283qt.c | 1 -
drivers/gpu/drm/tiny/repaper.c | 1 -
drivers/gpu/drm/tiny/st7586.c| 1 -
drivers/gpu/drm/tiny/st7735r.c | 1 -
drivers/gpu/drm/tve200/tve200_display.c | 1 -
drivers/gpu/drm/xen/xen_drm_front_kms.c | 1 -
14 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 098f96d4d50d..827e62c1daba 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -220,7 +220,6 @@ static const struct drm_simple_display_pipe_funcs
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
.enable_vblank = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
};
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index e8b672dc9832..1925df9c0fb7 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -364,7 +364,6 @@ static void gud_debugfs_init(struct drm_minor *minor)
static const struct drm_simple_display_pipe_funcs gud_pipe_funcs = {
.check = gud_pipe_check,
.update = gud_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_mode_config_funcs gud_mode_config_funcs = {
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 4ddc55d58f38..ce12a36e2db4 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -1479,7 +1479,6 @@ static struct drm_simple_display_pipe_funcs
mcde_display_funcs = {
.update = mcde_display_update,
.enable_vblank = mcde_display_enable_vblank,
.disable_vblank = mcde_display_disable_vblank,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
int mcde_display_init(struct drm_device *drm)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 6fd7f13f1aca..b5a8859739a2 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -440,7 +440,6 @@ static struct drm_simple_display_pipe_funcs
pl111_display_funcs = {
.enable = pl111_display_enable,
.disable = pl111_display_disable,
.update = pl111_display_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static int pl111_clk_div_choose_div(struct clk_hw *hw, unsigned long rate,
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index da5df93450de..9b33c05732aa 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -184,7 +184,6 @@ static const struct drm_simple_display_pipe_funcs
hx8357d_pipe_funcs = {
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_display_mode yx350hv15_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 69265d8a3beb..976d3209f164 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -328,7 +328,6 @@ static const struct drm_simple_display_pipe_funcs
ili9225_pipe_funcs = {
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = ili9225_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_display_mode ili9225_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index ad9ce7b4f76f..37e0c33399c8 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -140,7 +140,6 @@ static const struct drm_simple_display_pipe_funcs
ili9341_pipe_funcs = {
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disa
Re: [PATCH v2] libelf: improve PVH elfnote parsing
On Fri, May 21, 2021 at 07:26:21AM +0200, Juergen Gross wrote:
> On 20.05.21 11:28, Jan Beulich wrote:
> > On 20.05.2021 11:27, Roger Pau Monné wrote:
> > > On Wed, May 19, 2021 at 12:34:19PM +0200, Jan Beulich wrote:
> > > > On 18.05.2021 16:47, Roger Pau Monne wrote:
> > > > > @@ -425,8 +425,11 @@ static elf_errorstatus
> > > > > elf_xen_addr_calc_check(struct elf_binary *elf,
> > > > > return -1;
> > > > > }
> > > > > -/* Initial guess for virt_base is 0 if it is not explicitly
> > > > > defined. */
> > > > > -if ( parms->virt_base == UNSET_ADDR )
> > > > > +/*
> > > > > + * Initial guess for virt_base is 0 if it is not explicitly
> > > > > defined in the
> > > > > + * PV case. For PVH virt_base is forced to 0 because paging is
> > > > > disabled.
> > > > > + */
> > > > > +if ( parms->virt_base == UNSET_ADDR || hvm )
> > > > > {
> > > > > parms->virt_base = 0;
> > > > > elf_msg(elf, "ELF: VIRT_BASE unset, using %#" PRIx64 "\n",
> > > >
> > > > This message is wrong now if hvm is true but parms->virt_base !=
> > > > UNSET_ADDR.
> > > > Best perhaps is to avoid emitting the message altogether when hvm is
> > > > true.
> > > > (Since you'll be touching it anyway, perhaps a good opportunity
> > > > to do
> away
> > > > with passing parms->virt_base to elf_msg(), and instead simply use a
> > > > literal
> > > > zero.)
> > > >
> > > > > @@ -441,8 +444,10 @@ static elf_errorstatus
> > > > > elf_xen_addr_calc_check(struct elf_binary *elf,
> > > > >*
> > > > >* If we are using the modern ELF notes interface then the
> > > > > default
> > > > >* is 0.
> > > > > + *
> > > > > + * For PVH this is forced to 0, as it's already a
> > > > > legacy option
> for PV.
> > > > >*/
> > > > > -if ( parms->elf_paddr_offset == UNSET_ADDR )
> > > > > +if ( parms->elf_paddr_offset == UNSET_ADDR || hvm )
> > > > > {
> > > > > if ( parms->elf_note_start )
> > > >
> > > > Don't you want "|| hvm" here as well, or alternatively suppress the
> > > > fallback to the __xen_guest section in the PVH case (near the end of
> > > > elf_xen_parse())?
> > >
> > > The legacy __xen_guest section doesn't support PHYS32_ENTRY, so yes,
> > > that part could be completely skipped when called from an HVM
> > > container.
> > >
> > > I think I will fix that in another patch though if you are OK, as
> > > it's not strictly related to the calculation fixes done here.
> >
> > That's fine; it wants to be a prereq to the one here then, though,
> > I think.
>
> Would it be possible to add some comment to xen/include/public/elfnote.h
> Indicating which elfnotes are evaluated for which guest types,
For PVH after this patch the only mandatory note should be
PHYS32_ENTRY. BSD_SYMTAB is also parsed if found on that case.
> including
> a hint which elfnotes _have_ been evaluated before this series?
Before this patch mostly all PV notes are parsed, and you have to
manage to get suitable values set so that:
if ( (parms->virt_kstart > parms->virt_kend) ||
(parms->virt_entry < parms->virt_kstart) ||
(parms->virt_entry > parms->virt_kend) ||
(parms->virt_base > parms->virt_kstart) )
{
elf_err(elf, "ERROR: ELF start or entries are out of bounds\n");
return -1;
}
Doesn't trigger. That can be done by setting virt_entry or the native
elf entry point to a value that satisfies the condition. Or by setting
a suitable offset in VIRT_BASE to a value that matches the offset
added to the native entry point in the ELF header.
I can try to write this up, albeit I think it can get messy. Not sure
what's the best approach here regarding recommended settings to
satisfy old Xen versions.
Roger.
Re: [PATCH 0/8] xen: harden frontends against malicious backends
On Thu, May 13, 2021 at 12:02:54PM +0200, Juergen Gross wrote: > Xen backends of para-virtualized devices can live in dom0 kernel, dom0 > user land, or in a driver domain. This means that a backend might > reside in a less trusted environment than the Xen core components, so > a backend should not be able to do harm to a Xen guest (it can still > mess up I/O data, but it shouldn't be able to e.g. crash a guest by > other means or cause a privilege escalation in the guest). > > Unfortunately many frontends in the Linux kernel are fully trusting > their respective backends. This series is starting to fix the most > important frontends: console, disk and network. > > It was discussed to handle this as a security problem, but the topic > was discussed in public before, so it isn't a real secret. Is it based on patches we ship in Qubes[1] and also I've sent here some years ago[2]? I see a lot of similarities. If not, you may want to compare them. [1] https://github.com/QubesOS/qubes-linux-kernel/ [2] https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02336.html > Juergen Gross (8): > xen: sync include/xen/interface/io/ring.h with Xen's newest version > xen/blkfront: read response from backend only once > xen/blkfront: don't take local copy of a request from the ring page > xen/blkfront: don't trust the backend response data blindly > xen/netfront: read response from backend only once > xen/netfront: don't read data from request on the ring page > xen/netfront: don't trust the backend response data blindly > xen/hvc: replace BUG_ON() with negative return value > > drivers/block/xen-blkfront.c| 118 +- > drivers/net/xen-netfront.c | 184 ++--- > drivers/tty/hvc/hvc_xen.c | 15 +- > include/xen/interface/io/ring.h | 278 ++-- > 4 files changed, 369 insertions(+), 226 deletions(-) > > -- > 2.26.2 > > -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
[qemu-mainline test] 162108: regressions - FAIL
flight 162108 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162108/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 5/21/21 3:45 AM, Juergen Gross wrote: > On 21.05.21 09:26, Jan Beulich wrote: >> On 21.05.2021 09:18, Juergen Gross wrote: >>> On 20.05.21 14:08, Jan Beulich wrote: On 20.05.2021 13:57, Juergen Gross wrote: > On 20.05.21 13:42, Jan Beulich wrote: >> xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. >> For this to work when NX is not available, x86_configure_nx() needs > to >> be called first. >> >> Reported-by: Olaf Hering >> Signed-off-by: Jan Beulich > > Reviewed-by: Juergen Gross Thanks. I guess I forgot Cc: sta...@vger.kernel.org If you agree, can you please add this before pushing to Linus? >>> >>> Uh, just had a look why x86_configure_nx() was called after >>> xen_setup_gdt(). >>> >>> Upstream your patch will be fine, but before kernel 5.9 it will >>> break running as 32-bit PV guest (see commit 36104cb9012a82e7). >> >> Oh, indeed. That commit then actually introduced the issue here, >> and hence a Fixes: tag may be warranted. > > Added it already. :-) > > And I've limited the backport to happen not for 5.8 and older, of > course. Did something changed recently that this became a problem? That commit has been there for 3 years. Didn't Olaf report this to be a problem only on SLES kernels? -boris
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 21.05.2021 15:12, Boris Ostrovsky wrote: > > On 5/21/21 3:45 AM, Juergen Gross wrote: >> On 21.05.21 09:26, Jan Beulich wrote: >>> On 21.05.2021 09:18, Juergen Gross wrote: On 20.05.21 14:08, Jan Beulich wrote: > On 20.05.2021 13:57, Juergen Gross wrote: >> On 20.05.21 13:42, Jan Beulich wrote: >>> xen_setup_gdt(), via xen_load_gdt_boot(), wants to adjust page tables. >>> For this to work when NX is not available, x86_configure_nx() needs >> to >>> be called first. >>> >>> Reported-by: Olaf Hering >>> Signed-off-by: Jan Beulich >> >> Reviewed-by: Juergen Gross > > Thanks. I guess I forgot > > Cc: sta...@vger.kernel.org > > If you agree, can you please add this before pushing to Linus? Uh, just had a look why x86_configure_nx() was called after xen_setup_gdt(). Upstream your patch will be fine, but before kernel 5.9 it will break running as 32-bit PV guest (see commit 36104cb9012a82e7). >>> >>> Oh, indeed. That commit then actually introduced the issue here, >>> and hence a Fixes: tag may be warranted. >> >> Added it already. :-) >> >> And I've limited the backport to happen not for 5.8 and older, of >> course. > > > Did something changed recently that this became a problem? That commit has > been there for 3 years. He happened to try on a system where NX was turned off in the BIOS. That's not a setting you would usually find in use. > Didn't Olaf report this to be a problem only on SLES kernels? Which I assume have backports of the problematic change. Jan
[PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add missing virtio-mmio bits to Xen toolstack on Arm. The Virtio support for toolstack [1] was postponed as the main target was to upstream IOREQ/DM support on Arm in the first place. Now, we already have IOREQ support in, so we can resume Virtio enabling work. You can find previous discussion at [2]. Patch series [3] was reworked and rebased on recent "staging branch" (972ba1d x86/shadow: streamline shadow_get_page_from_l1e()) and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with "updated" virtio-mmio disk backend [4] running in Driver domain and unmodified Linux Guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. Any feedback/help would be highly appreciated. [1] https://lore.kernel.org/xen-devel/1610488352-18494-24-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1610488352-18494-25-git-send-email-olekst...@gmail.com/ [2] https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02403.html https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02536.html [3] https://github.com/otyshchenko1/xen/commits/libxl_virtio [4] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml3 Julien Grall (1): libxl: Introduce basic virtio-mmio support on Arm Oleksandr Tyshchenko (1): libxl: Add support for Virtio disk configuration docs/man/xl-disk-configuration.5.pod.in | 27 + tools/include/libxl.h | 6 + tools/libs/light/libxl_arm.c | 133 - tools/libs/light/libxl_device.c | 38 +- tools/libs/light/libxl_disk.c | 99 +++- tools/libs/light/libxl_types.idl | 4 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c| 2 + tools/libs/util/libxlu_disk_l.c | 881 +++--- tools/libs/util/libxlu_disk_l.h | 2 +- tools/libs/util/libxlu_disk_l.l | 1 + tools/xl/xl_block.c | 11 + xen/include/public/arch-arm.h | 7 + 13 files changed, 764 insertions(+), 448 deletions(-) -- 2.7.4
[PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
From: Julien Grall
Date: Wed, 29 Jul 2020 17:36:53 +0300
Subject: [PATCH V5 2/2] libxl: Introduce basic virtio-mmio support on Arm
This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory region) and create specific device node in
the Guest device-tree with allocated params. In order to deal
with multiple Virtio devices, reserve corresponding ranges.
For now, we reserve 1MB for memory regions and 10 SPIs.
As these helpers should be used for every Virtio device attached
to the Guest, call them for Virtio disk(s).
Please note, with statically allocated Virtio IRQs there is
a risk of a clash with a physical IRQs of passthrough devices.
For the first version, it's fine, but we should consider allocating
the Virtio IRQs automatically. Thankfully, we know in advance which
IRQs will be used for passthrough to be able to choose non-clashed
ones.
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forwarding to a device emulator"
Changes RFC -> V1:
- was squashed with:
"[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
"[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into
virtio-mmio device node"
"[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
- move VirtIO MMIO #define-s to xen/include/public/arch-arm.h
Changes V1 -> V2:
- update the author of a patch
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- no changes
Changes V4 -> V5:
- split the changes, change the order of the patches
- drop an extra "virtio" configuration option
- update patch description
- use CONTAINER_OF instead of own implementation
- reserve ranges for Virtio MMIO params and put them
in correct location
- create helpers to allocate Virtio MMIO params, add
corresponding sanity-сhecks
- add comment why MMIO size 0x200 is chosen
- update debug print
- drop Wei's T-b
---
tools/libs/light/libxl_arm.c | 133 +-
xen/include/public/arch-arm.h | 7 +++
2 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index e2901f1..a9f15ce 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -8,6 +8,56 @@
#include
#include
+/*
+ * There is no clear requirements for the total size of Virtio MMIO region.
+ * The size of control registers is 0x100 and device-specific configuration
+ * registers starts at the offset 0x100, however it's size depends on the
device
+ * and the driver. Pick the biggest known size at the moment to cover most
+ * of the devices (also consider allowing the user to configure the size via
+ * config file for the one not conforming with the proposed value).
+ */
+#define VIRTIO_MMIO_DEV_SIZE xen_mk_ullong(0x200)
+
+static uint64_t virtio_mmio_base;
+static uint32_t virtio_mmio_irq;
+
+static void init_virtio_mmio_params(void)
+{
+virtio_mmio_base = GUEST_VIRTIO_MMIO_BASE;
+virtio_mmio_irq = GUEST_VIRTIO_MMIO_SPI_FIRST;
+}
+
+static uint64_t alloc_virtio_mmio_base(libxl__gc *gc)
+{
+uint64_t base = virtio_mmio_base;
+
+/* Make sure we have enough reserved resources */
+if ((virtio_mmio_base + VIRTIO_MMIO_DEV_SIZE >
+GUEST_VIRTIO_MMIO_BASE + GUEST_VIRTIO_MMIO_SIZE)) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO BASE
0x%"PRIx64"\n",
+virtio_mmio_base);
+return 0;
+}
+virtio_mmio_base += VIRTIO_MMIO_DEV_SIZE;
+
+return base;
+}
+
+static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc)
+{
+uint32_t irq = virtio_mmio_irq;
+
+/* Make sure we have enough reserved resources */
+if (virtio_mmio_irq > GUEST_VIRTIO_MMIO_SPI_LAST) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO IRQ %u\n",
+virtio_mmio_irq);
+return 0;
+}
+virtio_mmio_irq++;
+
+return irq;
+}
+
static const char *gicv_to_string(libxl_gic_version gic_version)
{
switch (gic_version) {
@@ -26,8 +76,8 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
{
uint32_t nr_spis = 0;
unsigned int i;
-uint32_t vuart_irq;
-bool vuart_enabled = false;
+uint32_t vuart_irq, virtio_irq = 0;
+bool vuart_enabled = false, virtio_enabled = false;
/*
* If pl011 vuart is enabled then increment the nr_spis to allow allocation
@@ -39,6 +89,35 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
vuart_enabled = true;
}
+/*
+ * Virtio MMIO params are non-unique across the whole system and must be
+ * initialized for every new guest.
+ */
+init_virtio_mmio_params();
+for (i = 0; i < d_config->num_disks; i++) {
+libxl_device_disk *disk = &d_config->disks[i];
+
+if (disk->virtio) {
+disk->base = alloc_virtio_mmio_base(gc);
+if (!disk->base)
+
[PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
From: Oleksandr Tyshchenko Date: Thu, 20 May 2021 20:41:01 +0300 Subject: [PATCH V5 1/2] libxl: Add support for Virtio disk configuration This patch adds basic support for configuring and assisting virtio-disk backend (emualator) which is intended to run out of Qemu and could be run in any domain. Although the Virtio block device is quite different from traditional Xen PV block device (vbd) from the toolstack point of view: - the frontend is virtio-blk which is not a Xenbus driver, so nothing written to Xenstore are fetched by the frontend (the vdev is not passed to the frontend, etc) - the ring-ref/event-channel are not used for the backend<->frontend communication, the proposed IPC for Virtio is IOREQ/DM it is still a "block device" and ought to be integrated in existing "disk" handling. So, re-use (and adapt) "disk" parsing/configuration logic to deal with Virtio devices as well. Besides introducing new disk backend type (LIBXL_DISK_BACKEND_VIRTIO) introduce new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model. In order to inform the toolstack that Virtio disk needs to be used extend "disk" configuration by introducing new "virtio" flag. An example of domain configuration: disk = [ 'backend=DomD, phy:/dev/mmcblk1p3, xvda1, rw, virtio' ] Please note, this patch is not enough for virtio-disk to work on Xen (Arm), as for every Virtio device (including disk) we need to allocate Virtio MMIO params (IRQ and memory region) and pass them to the backend, also update Guest device-tree with the allocated params. The subsequent patch will add these missing bits. For the current patch, the default "irq" and "base" are just written to the Xenstore. Signed-off-by: Oleksandr Tyshchenko --- Changes RFC -> V1: - no changes Changes V1 -> V2: - rebase according to the new location of libxl_virtio_disk.c Changes V2 -> V3: - no changes Changes V3 -> V4: - rebase according to the new argument for DEFINE_DEVICE_TYPE_STRUCT Changes V4 -> V5: - split the changes, change the order of the patches - update patch description - don't introduce new "vdisk" configuration option with own parsing logic, re-use Xen PV block "disk" parsing/configuration logic for the virtio-disk - introduce "virtio" flag and document it's usage - add LIBXL_HAVE_DEVICE_DISK_VIRTIO - update libxlu_disk_l.[ch] - drop num_disks variable/MAX_VIRTIO_DISKS - drop Wei's T-b --- docs/man/xl-disk-configuration.5.pod.in | 27 + tools/include/libxl.h | 6 + tools/libs/light/libxl_device.c | 38 +- tools/libs/light/libxl_disk.c | 99 +++- tools/libs/light/libxl_types.idl | 4 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c| 2 + tools/libs/util/libxlu_disk_l.c | 881 +++--- tools/libs/util/libxlu_disk_l.h | 2 +- tools/libs/util/libxlu_disk_l.l | 1 + tools/xl/xl_block.c | 11 + 11 files changed, 626 insertions(+), 446 deletions(-) diff --git a/docs/man/xl-disk-configuration.5.pod.in b/docs/man/xl-disk-configuration.5.pod.in index 71d0e86..9cc189f 100644 --- a/docs/man/xl-disk-configuration.5.pod.in +++ b/docs/man/xl-disk-configuration.5.pod.in @@ -344,8 +344,35 @@ can be used to disable "hole punching" for file based backends which were intentionally created non-sparse to avoid fragmentation of the file. +=item B + +=over 4 + +=item Description + +Enables experimental Virtio support for disk + +=item Supported values + +absent, present + +=item Mandatory + +No + +=item Default value + +absent + =back +Besides forcing toolstack to use specific Xen Virtio backend implementation +(for example, virtio-disk), this also affects the guest's view of the device +and requires virtio-blk driver to be used. +Please note, the virtual device (vdev) is not passed to the guest in that case, +but it still must be specified for the internal purposes. + +=back =head1 COLO Parameters diff --git a/tools/include/libxl.h b/tools/include/libxl.h index ae7fe27..58e14e6 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -503,6 +503,12 @@ #define LIBXL_HAVE_X86_MSR_RELAXED 1 /* + * LIBXL_HAVE_DEVICE_DISK_VIRTIO indicates that a 'virtio' field + * (of boolean type) is present in libxl_device_disk. + */ +#define LIBXL_HAVE_DEVICE_DISK_VIRTIO 1 + +/* * libxl ABI compatibility * * The only guarantee which libxl makes regarding ABI compatibility diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c index 36c4e41..7c8cb53 100644 --- a/tools/libs/light/libxl_device.c +++ b/tools/libs/light/libxl_device.c @@ -292,6 +292,9 @@ static int disk_try_backend(disk_try_backend_args *a, /* returns 0 (ie, DISK_BACKEND_UNKNOWN) on failure, or * backend on success */ +if (a->disk->virtio && backend != LIBXL_DISK
Re: [PATCH] x86/Xen: swap NX determination and GDT setup on BSP
On 5/21/21 9:15 AM, Jan Beulich wrote: > On 21.05.2021 15:12, Boris Ostrovsky wrote: >> >> Did something changed recently that this became a problem? That commit has >> been there for 3 years. > He happened to try on a system where NX was turned off in the BIOS. Yes, I missed that part. -boris
Re: [PATCH v3 1/2] libelf: don't attempt to parse __xen_guest for PVH
On 20.05.2021 14:35, Jan Beulich wrote: > On 20.05.2021 14:30, Roger Pau Monne wrote: >> The legacy __xen_guest section doesn't support the PHYS32_ENTRY >> elfnote, so it's pointless to attempt to parse the elfnotes from that >> section when called from an hvm container. >> >> Suggested-by: Jan Beulich >> Signed-off-by: Roger Pau Monné >> --- >> Changes since v2: >> - New in this version. >> --- >> xen/common/libelf/libelf-dominfo.c | 6 ++ >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/xen/common/libelf/libelf-dominfo.c >> b/xen/common/libelf/libelf-dominfo.c >> index 69c94b6f3bb..abea1011c18 100644 >> --- a/xen/common/libelf/libelf-dominfo.c >> +++ b/xen/common/libelf/libelf-dominfo.c >> @@ -577,10 +577,8 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf, >> >> } >> >> -/* >> - * Finally fall back to the __xen_guest section. >> - */ >> -if ( xen_elfnotes == 0 ) >> +/* Finally fall back to the __xen_guest section for PV guests only. */ >> +if ( xen_elfnotes == 0 && !hvm ) > > Isn't this depending on the 2nd patch adding the function parameter? > IOW doesn't this break the build, even if just transiently? With the > respective hunk from patch 2 moved here > Reviewed-by: Jan Beulich With the intention of committing I did this hunk movement, noticing that - it's more than just one hunk, - a tool stack maintainer ack is actually going to be needed (all respective hunks are now in the first patch). I'll keep the massaged patches locally, until the missing ack arrives. Jan
[ovmf test] 162111: all pass - PUSHED
flight 162111 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162111/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 04ae17218deec25c6f488609c5e2ca9c419d2c4b baseline version: ovmf 15ee7b76891a78141e6e30ef3f8572e8d6b326d2 Last test of basis 162071 2021-05-19 01:40:34 Z2 days Testing same since 162111 2021-05-21 07:11:13 Z0 days1 attempts People who touched revisions under test: Garrett Kirkendall jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 15ee7b7689..04ae17218d 04ae17218deec25c6f488609c5e2ca9c419d2c4b -> xen-tested-master
Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 4:09 AM, Daniel Vetter wrote: Goes through all the drivers and deletes the default hook since it's the default now. Acked-by: David Lechner
Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
Den 21.05.2021 11.09, skrev Daniel Vetter: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Noralf Trønnes
Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 12:09 PM, Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Oleksandr Andrushchenko
[xen-unstable test] 162107: tolerable FAIL
flight 162107 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/162107/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162102 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 162102 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 162102 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 162102 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 162102 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 162102 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 162102 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 162102 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 162102 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 162102 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162102 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: xen aa77acc28098d04945af998f3fc0dbd3759b5b41 baseline version: xen aa77acc28098d04945af998f3fc0dbd3759b5b41 Last test of basis 162107 2021-05-21 01:53:46 Z0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64
[linux-linus test] 162109: regressions - FAIL
flight 162109 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162109/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 14 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-check
[RESEND PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add missing virtio-mmio bits to Xen toolstack on Arm. The Virtio support for toolstack [1] was postponed as the main target was to upstream IOREQ/DM support on Arm in the first place. Now, we already have IOREQ support in, so we can resume Virtio enabling work. You can find previous discussion at [2]. Patch series [3] was reworked and rebased on recent "staging branch" (972ba1d x86/shadow: streamline shadow_get_page_from_l1e()) and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with "updated" virtio-mmio disk backend [4] running in Driver domain and unmodified Linux Guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. Any feedback/help would be highly appreciated. [1] https://lore.kernel.org/xen-devel/1610488352-18494-24-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1610488352-18494-25-git-send-email-olekst...@gmail.com/ [2] https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02403.html https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02536.html [3] https://github.com/otyshchenko1/xen/commits/libxl_virtio [4] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml3 Julien Grall (1): libxl: Introduce basic virtio-mmio support on Arm Oleksandr Tyshchenko (1): libxl: Add support for Virtio disk configuration docs/man/xl-disk-configuration.5.pod.in | 27 + tools/include/libxl.h | 6 + tools/libs/light/libxl_arm.c | 133 - tools/libs/light/libxl_device.c | 38 +- tools/libs/light/libxl_disk.c | 99 +++- tools/libs/light/libxl_types.idl | 4 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c| 2 + tools/libs/util/libxlu_disk_l.c | 881 +++--- tools/libs/util/libxlu_disk_l.h | 2 +- tools/libs/util/libxlu_disk_l.l | 1 + tools/xl/xl_block.c | 11 + xen/include/public/arch-arm.h | 7 + 13 files changed, 764 insertions(+), 448 deletions(-) -- 2.7.4
[RESEND PATCH V5 2/2] libxl: Introduce basic virtio-mmio support on Arm
From: Julien Grall
This patch introduces helpers to allocate Virtio MMIO params
(IRQ and memory region) and create specific device node in
the Guest device-tree with allocated params. In order to deal
with multiple Virtio devices, reserve corresponding ranges.
For now, we reserve 1MB for memory regions and 10 SPIs.
As these helpers should be used for every Virtio device attached
to the Guest, call them for Virtio disk(s).
Please note, with statically allocated Virtio IRQs there is
a risk of a clash with a physical IRQs of passthrough devices.
For the first version, it's fine, but we should consider allocating
the Virtio IRQs automatically. Thankfully, we know in advance which
IRQs will be used for passthrough to be able to choose non-clashed
ones.
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forwarding to a device emulator"
Changes RFC -> V1:
- was squashed with:
"[RFC PATCH V1 09/12] libxl: Handle virtio-mmio irq in more correct way"
"[RFC PATCH V1 11/12] libxl: Insert "dma-coherent" property into
virtio-mmio device node"
"[RFC PATCH V1 12/12] libxl: Fix duplicate memory node in DT"
- move VirtIO MMIO #define-s to xen/include/public/arch-arm.h
Changes V1 -> V2:
- update the author of a patch
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- no changes
Changes V4 -> V5:
- split the changes, change the order of the patches
- drop an extra "virtio" configuration option
- update patch description
- use CONTAINER_OF instead of own implementation
- reserve ranges for Virtio MMIO params and put them
in correct location
- create helpers to allocate Virtio MMIO params, add
corresponding sanity-сhecks
- add comment why MMIO size 0x200 is chosen
- update debug print
- drop Wei's T-b
---
---
tools/libs/light/libxl_arm.c | 133 +-
xen/include/public/arch-arm.h | 7 +++
2 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index e2901f1..a9f15ce 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -8,6 +8,56 @@
#include
#include
+/*
+ * There is no clear requirements for the total size of Virtio MMIO region.
+ * The size of control registers is 0x100 and device-specific configuration
+ * registers starts at the offset 0x100, however it's size depends on the
device
+ * and the driver. Pick the biggest known size at the moment to cover most
+ * of the devices (also consider allowing the user to configure the size via
+ * config file for the one not conforming with the proposed value).
+ */
+#define VIRTIO_MMIO_DEV_SIZE xen_mk_ullong(0x200)
+
+static uint64_t virtio_mmio_base;
+static uint32_t virtio_mmio_irq;
+
+static void init_virtio_mmio_params(void)
+{
+virtio_mmio_base = GUEST_VIRTIO_MMIO_BASE;
+virtio_mmio_irq = GUEST_VIRTIO_MMIO_SPI_FIRST;
+}
+
+static uint64_t alloc_virtio_mmio_base(libxl__gc *gc)
+{
+uint64_t base = virtio_mmio_base;
+
+/* Make sure we have enough reserved resources */
+if ((virtio_mmio_base + VIRTIO_MMIO_DEV_SIZE >
+GUEST_VIRTIO_MMIO_BASE + GUEST_VIRTIO_MMIO_SIZE)) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO BASE
0x%"PRIx64"\n",
+virtio_mmio_base);
+return 0;
+}
+virtio_mmio_base += VIRTIO_MMIO_DEV_SIZE;
+
+return base;
+}
+
+static uint32_t alloc_virtio_mmio_irq(libxl__gc *gc)
+{
+uint32_t irq = virtio_mmio_irq;
+
+/* Make sure we have enough reserved resources */
+if (virtio_mmio_irq > GUEST_VIRTIO_MMIO_SPI_LAST) {
+LOG(ERROR, "Ran out of reserved range for Virtio MMIO IRQ %u\n",
+virtio_mmio_irq);
+return 0;
+}
+virtio_mmio_irq++;
+
+return irq;
+}
+
static const char *gicv_to_string(libxl_gic_version gic_version)
{
switch (gic_version) {
@@ -26,8 +76,8 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
{
uint32_t nr_spis = 0;
unsigned int i;
-uint32_t vuart_irq;
-bool vuart_enabled = false;
+uint32_t vuart_irq, virtio_irq = 0;
+bool vuart_enabled = false, virtio_enabled = false;
/*
* If pl011 vuart is enabled then increment the nr_spis to allow allocation
@@ -39,6 +89,35 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
vuart_enabled = true;
}
+/*
+ * Virtio MMIO params are non-unique across the whole system and must be
+ * initialized for every new guest.
+ */
+init_virtio_mmio_params();
+for (i = 0; i < d_config->num_disks; i++) {
+libxl_device_disk *disk = &d_config->disks[i];
+
+if (disk->virtio) {
+disk->base = alloc_virtio_mmio_base(gc);
+if (!disk->base)
+return ERROR_FAIL;
+
+disk->irq = alloc_virtio_mmio_irq(gc);
+if (!disk->irq)
+
[RESEND PATCH V5 1/2] libxl: Add support for Virtio disk configuration
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be
run in any domain.
Although the Virtio block device is quite different from traditional
Xen PV block device (vbd) from the toolstack point of view:
- the frontend is virtio-blk which is not a Xenbus driver, so nothing
written to Xenstore are fetched by the frontend (the vdev is not
passed to the frontend, etc)
- the ring-ref/event-channel are not used for the backend<->frontend
communication, the proposed IPC for Virtio is IOREQ/DM
it is still a "block device" and ought to be integrated in existing
"disk" handling. So, re-use (and adapt) "disk" parsing/configuration
logic to deal with Virtio devices as well.
Besides introducing new disk backend type (LIBXL_DISK_BACKEND_VIRTIO)
introduce new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model.
In order to inform the toolstack that Virtio disk needs to be used
extend "disk" configuration by introducing new "virtio" flag.
An example of domain configuration:
disk = [ 'backend=DomD, phy:/dev/mmcblk1p3, xvda1, rw, virtio' ]
Please note, this patch is not enough for virtio-disk to work
on Xen (Arm), as for every Virtio device (including disk) we need
to allocate Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree with the allocated
params. The subsequent patch will add these missing bits.
For the current patch, the default "irq" and "base" are just written
to the Xenstore.
Signed-off-by: Oleksandr Tyshchenko
---
Changes RFC -> V1:
- no changes
Changes V1 -> V2:
- rebase according to the new location of libxl_virtio_disk.c
Changes V2 -> V3:
- no changes
Changes V3 -> V4:
- rebase according to the new argument for DEFINE_DEVICE_TYPE_STRUCT
Changes V4 -> V5:
- split the changes, change the order of the patches
- update patch description
- don't introduce new "vdisk" configuration option with own parsing logic,
re-use Xen PV block "disk" parsing/configuration logic for the virtio-disk
- introduce "virtio" flag and document it's usage
- add LIBXL_HAVE_DEVICE_DISK_VIRTIO
- update libxlu_disk_l.[ch]
- drop num_disks variable/MAX_VIRTIO_DISKS
- drop Wei's T-b
---
---
docs/man/xl-disk-configuration.5.pod.in | 27 +
tools/include/libxl.h | 6 +
tools/libs/light/libxl_device.c | 38 +-
tools/libs/light/libxl_disk.c | 99 +++-
tools/libs/light/libxl_types.idl | 4 +
tools/libs/light/libxl_types_internal.idl | 1 +
tools/libs/light/libxl_utils.c| 2 +
tools/libs/util/libxlu_disk_l.c | 881 +++---
tools/libs/util/libxlu_disk_l.h | 2 +-
tools/libs/util/libxlu_disk_l.l | 1 +
tools/xl/xl_block.c | 11 +
11 files changed, 626 insertions(+), 446 deletions(-)
diff --git a/docs/man/xl-disk-configuration.5.pod.in
b/docs/man/xl-disk-configuration.5.pod.in
index 71d0e86..9cc189f 100644
--- a/docs/man/xl-disk-configuration.5.pod.in
+++ b/docs/man/xl-disk-configuration.5.pod.in
@@ -344,8 +344,35 @@ can be used to disable "hole punching" for file based
backends which
were intentionally created non-sparse to avoid fragmentation of the
file.
+=item B
+
+=over 4
+
+=item Description
+
+Enables experimental Virtio support for disk
+
+=item Supported values
+
+absent, present
+
+=item Mandatory
+
+No
+
+=item Default value
+
+absent
+
=back
+Besides forcing toolstack to use specific Xen Virtio backend implementation
+(for example, virtio-disk), this also affects the guest's view of the device
+and requires virtio-blk driver to be used.
+Please note, the virtual device (vdev) is not passed to the guest in that case,
+but it still must be specified for the internal purposes.
+
+=back
=head1 COLO Parameters
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index ae7fe27..58e14e6 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -503,6 +503,12 @@
#define LIBXL_HAVE_X86_MSR_RELAXED 1
/*
+ * LIBXL_HAVE_DEVICE_DISK_VIRTIO indicates that a 'virtio' field
+ * (of boolean type) is present in libxl_device_disk.
+ */
+#define LIBXL_HAVE_DEVICE_DISK_VIRTIO 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c
index 36c4e41..7c8cb53 100644
--- a/tools/libs/light/libxl_device.c
+++ b/tools/libs/light/libxl_device.c
@@ -292,6 +292,9 @@ static int disk_try_backend(disk_try_backend_args *a,
/* returns 0 (ie, DISK_BACKEND_UNKNOWN) on failure, or
* backend on success */
+if (a->disk->virtio && backend != LIBXL_DISK_BACKEND_VIRTIO)
+goto bad_virtio;
+
switch (backend) {
case LIBXL_DISK_BACKEND_PHY:
Re: [PATCH V5 0/2] Virtio support for toolstack on Arm (Was "IOREQ feature (+ virtio-mmio) on Arm")
On 21.05.21 16:16, Oleksandr Tyshchenko wrote: Hello, all. I pushed this series in wrong way, so the patches #1 and #2 appeared with the same subject as a cover letter. I have just resent this patch series properly. Please ignore current one. Sorry for the noise. https://lore.kernel.org/xen-devel/1621626361-29076-1-git-send-email-olekst...@gmail.com/ From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add missing virtio-mmio bits to Xen toolstack on Arm. The Virtio support for toolstack [1] was postponed as the main target was to upstream IOREQ/DM support on Arm in the first place. Now, we already have IOREQ support in, so we can resume Virtio enabling work. You can find previous discussion at [2]. Patch series [3] was reworked and rebased on recent "staging branch" (972ba1d x86/shadow: streamline shadow_get_page_from_l1e()) and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with "updated" virtio-mmio disk backend [4] running in Driver domain and unmodified Linux Guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. Any feedback/help would be highly appreciated. [1] https://lore.kernel.org/xen-devel/1610488352-18494-24-git-send-email-olekst...@gmail.com/ https://lore.kernel.org/xen-devel/1610488352-18494-25-git-send-email-olekst...@gmail.com/ [2] https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02403.html https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg02536.html [3] https://github.com/otyshchenko1/xen/commits/libxl_virtio [4] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml3 Julien Grall (1): libxl: Introduce basic virtio-mmio support on Arm Oleksandr Tyshchenko (1): libxl: Add support for Virtio disk configuration docs/man/xl-disk-configuration.5.pod.in | 27 + tools/include/libxl.h | 6 + tools/libs/light/libxl_arm.c | 133 - tools/libs/light/libxl_device.c | 38 +- tools/libs/light/libxl_disk.c | 99 +++- tools/libs/light/libxl_types.idl | 4 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c| 2 + tools/libs/util/libxlu_disk_l.c | 881 +++--- tools/libs/util/libxlu_disk_l.h | 2 +- tools/libs/util/libxlu_disk_l.l | 1 + tools/xl/xl_block.c | 11 + xen/include/public/arch-arm.h | 7 + 13 files changed, 764 insertions(+), 448 deletions(-) -- Regards, Oleksandr Tyshchenko
[ovmf test] 162113: all pass - PUSHED
flight 162113 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/162113/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1fb80369b72c6ba7f80b442e4acf771a6dd56ee7 baseline version: ovmf 04ae17218deec25c6f488609c5e2ca9c419d2c4b Last test of basis 162111 2021-05-21 07:11:13 Z0 days Testing same since 162113 2021-05-21 13:41:10 Z0 days1 attempts People who touched revisions under test: Li, Walon Walon Li jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 04ae17218d..1fb80369b7 1fb80369b72c6ba7f80b442e4acf771a6dd56ee7 -> xen-tested-master
[qemu-mainline test] 162112: regressions - FAIL
flight 162112 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162112/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass
[qemu-mainline bisection] complete test-amd64-amd64-qemuu-freebsd11-amd64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-freebsd11-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://git.qemu.org/qemu.git
Bug introduced: 1b507e55f8199eaad99744613823f6929e4d57c6
Bug not present: 4083904bc9fe5da580f7ca397b1e828fbc322732
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/160218/
commit 1b507e55f8199eaad99744613823f6929e4d57c6
Merge: 4083904bc9 8d17adf34f
Author: Peter Maydell
Date: Thu Mar 18 19:00:49 2021 +
Merge remote-tracking branch
'remotes/berrange-gitlab/tags/dep-many-pull-request' into staging
Remove many old deprecated features
The following features have been deprecated for well over the 2
release cycle we promise
``-drive file=json:{...{'driver':'file'}}`` (since 3.0)
``-vnc acl`` (since 4.0.0)
``-mon ...,control=readline,pretty=on|off`` (since 4.1)
``migrate_set_downtime`` and ``migrate_set_speed`` (since 2.8.0)
``query-named-block-nodes`` result ``encryption_key_missing`` (since
2.10.0)
``query-block`` result ``inserted.encryption_key_missing`` (since
2.10.0)
``migrate-set-cache-size`` and ``query-migrate-cache-size`` (since
2.11.0)
``query-named-block-nodes`` and ``query-block`` result
dirty-bitmaps[i].status (since 4.0)
``query-cpus`` (since 2.12.0)
``query-cpus-fast`` ``arch`` output member (since 3.0.0)
``query-events`` (since 4.0)
chardev client socket with ``wait`` option (since 4.0)
``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``,
``acl_remove`` (since 4.0.0)
``ide-drive`` (since 4.2)
``scsi-disk`` (since 4.2)
# gpg: Signature made Thu 18 Mar 2021 09:23:39 GMT
# gpg:using RSA key
DAF3A6FDB26B62912D0E8E3FBE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange " [full]
# gpg: aka "Daniel P. Berrange "
[full]
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510
4FDF
* remotes/berrange-gitlab/tags/dep-many-pull-request:
block: remove support for using "file" driver with block/char devices
block: remove 'dirty-bitmaps' field from 'BlockInfo' struct
block: remove dirty bitmaps 'status' field
block: remove 'encryption_key_missing' flag from QAPI
hw/scsi: remove 'scsi-disk' device
hw/ide: remove 'ide-drive' device
chardev: reject use of 'wait' flag for socket client chardevs
machine: remove 'arch' field from 'query-cpus-fast' QMP command
machine: remove 'query-cpus' QMP command
migrate: remove QMP/HMP commands for speed, downtime and cache size
monitor: remove 'query-events' QMP command
monitor: raise error when 'pretty' option is used with HMP
ui, monitor: remove deprecated VNC ACL option and HMP commands
Signed-off-by: Peter Maydell
commit 8d17adf34f501ded65a106572740760f0a75577c
Author: Daniel P. Berrangé
Date: Mon Feb 22 11:16:32 2021 +
block: remove support for using "file" driver with block/char devices
The 'host_device' and 'host_cdrom' drivers must be used instead.
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrangé
commit e67d8e2928200e24ecb47c7be3ea8270077f2996
Author: Daniel P. Berrangé
Date: Fri Feb 19 19:22:36 2021 +
block: remove 'dirty-bitmaps' field from 'BlockInfo' struct
The same data is available in the 'BlockDeviceInfo' struct.
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Daniel P. Berrangé
commit 81cbfd5088690c53541ffd0d74851c8ab055a829
Author: Daniel P. Berrangé
Date: Fri Feb 19 19:19:54 2021 +
block: remove dirty bitmaps 'status' field
The same information is available via the 'recording' and 'busy' fields.
Reviewed-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Daniel P. Berrangé
commit ad1324e044240ae9fcf67e4c215481b7a35591b9
Author: Daniel P. Berrangé
Date: Fri Feb 19 18:53:17 2021 +
block: remove 'encryption_key_missing' flag from QAPI
This has been hardcoded to "false" since 2.10.0, since secrets required
to unlock block devices are now always provided up front instead of using
interactive prompts.
Reviewed-by: Eric Blake
Reviewed-by: Thomas Huth
Signed-off-by: Daniel P. Berrangé
[linux-linus test] 162114: regressions - FAIL
flight 162114 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162114/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 13 debian-fixup fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 13 debian-fixup fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-check
[qemu-mainline test] 162116: regressions - FAIL
flight 162116 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162116/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass
[libvirt test] 162120: regressions - FAIL
flight 162120 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/162120/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt d8c468d58c23cf4254fb9812b4f0225b184a baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 316 days Failing since151818 2020-07-11 04:18:52 Z 315 days 308 attempts Testing same since 162120 2021-05-22 04:20:08 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle SeongHyun Jo Shalini Chellathurai Saroja Shaojun Yang Shi Lei simmon Simon Gaiser Stefan Bader Stefan Berger Stefan Berger Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Ville Skyttä Wang Xin WangJian Weblate Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yaroslav Kargin Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
