[ovmf test] 150050: all pass - PUSHED
flight 150050 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150050/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f159102a130fac9b416418eb9b6fa35b63426ca5 baseline version: ovmf de15e7c2651ada46cc649c5b3c8c0c145354ac04 Last test of basis 150045 2020-05-05 16:09:42 Z1 days Testing same since 150050 2020-05-05 20:40:09 Z1 days1 attempts People who touched revisions under test: Rebecca Cran 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 de15e7c265..f159102a13 f159102a130fac9b416418eb9b6fa35b63426ca5 -> xen-tested-master
[libvirt test] 150053: regressions - FAIL
flight 150053 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150053/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-amd64-amd64-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-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 0756415f147dda15a417bd79eef9a62027d176e6 baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 110 days Failing since146211 2020-01-18 04:18:52 Z 110 days 100 attempts Testing same since 150053 2020-05-06 04:19:32 Z1 days1 attempts People who touched revisions under test: Andrea Bolognani Arnaud Patard Bjoern Walk Boris Fiuczynski Chen Hanxiao Christian Borntraeger Christian Ehrhardt Christian Schoenebeck Collin Walling Cornelia Huck Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Gaurav Agrawal Han Han Jamie Strandboge Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Leonid Bloch Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mark Asselstine Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Pavel Mores Peter Krempa Philipp Hahn Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tobin Feldman-Fitzthum Wu Qingliang Xu Yandong Yi Li Your Name Zhang Bo zhenwei pi Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair
[qemu-mainline test] 150043: tolerable FAIL - PUSHED
flight 150043 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150043/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 149911 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 149911 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 149911 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 149911 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 149911 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 149911 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 149911 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: qemuuf19d118bed77bb95681b07f4e76dbb700c16918d baseline version: qemuu2ef486e76d64436be90f7359a3071fb2a56ce835 Last test of basis 149911 2020-05-03 14:06:59 Z3 days Testing same since 150043 2020-05-05 16:07:08 Z1 days1 attempts People who touched revisions under test: Alexander Bulekov Anthoine Bourgeois Chen Qun Daniel Brodsky David Gibson Edgar E. Iglesias Eric Auger Eric Blake Fredrik Strupe Gerd Hoffmann John Snow Julia Suvorova Keith Busch Kwangwoo Lee Laurent Vivier Li Feng Liran Alon Max Reitz Michael S. Tsirkin Michael Walle Mikhail Gusarov Peter Maydell Peter Turschmid Philippe Mathieu-Daudé Philippe Mathieu-Daudé Raphael
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, May 6, 2020 at 10:34 AM Stefano Stabellini
wrote:
>
> On Wed, 6 May 2020, Nataliya Korovkina wrote:
> > On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> > wrote:
> > >
> > >
> > > On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> > > > Hello,
> > > >
> > > > What I found out: rpi_firmware_property_list() allocates memory from
> > > > dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page()
> > > > is not eligible in this case.
> > >
> > >
> > > So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In
> > > which case it has no business calling xen_swiotlb_free_coherent().
> > >
> > >
> > > -boris
> > >
> > >
> > >
> > >
> >
> > It does go.
> > dma_alloc_coherent() indirectly calls xen_swiotlb_alloc_coherent(),
> > then xen_alloc_coherent_pages() eventually calls arch_dma_alloc() in
> > remap.c which successfully allocates pages from atomic pool.
> >
> > The patch Julien offered for domian_build.c moved Dom0 banks in the
> > first G of RAM.
> > So it covered the previous symptom (a crash during allocation) because
> > now we avoid pathway when we mark a page "XenMapped".
> >
> > But the symptom still remains in xen_swiotlb_free_coherent() because
> > "TestPage..." is called unconditionally. virt_to_page() is not
> > applicable to such allocations.
>
> Ah! So this is the crux of the issue. I saw this kind of problem before
> on ARM32 (in fact there are several comments warning not to use
> virt_to_phys on ARM in drivers/xen/swiotlb-xen.c).
>
>
> So, to recap we have 2 issues as far as I can tell:
>
> - virt_to_page not working in some cases on ARM, leading to a crash
> - WARN_ON for range_straddles_page_boundary which is normal on ARM
>
> The appended patch addresses them by:
>
> - using pfn_to_page instead virt_to_page
> - moving the WARN_ON under a #ifdef (Juergen might have a better
> suggestion on how to rework the WARN_ON)
>
> Please let me know if this patch works!
>
> Cheers,
>
> Stefano
>
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b6d27762c6f8..0a40ac332a4c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -322,7 +322,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
> size,
> xen_free_coherent_pages(hwdev, size, ret,
> (dma_addr_t)phys, attrs);
> return NULL;
> }
> - SetPageXenRemapped(virt_to_page(ret));
> + SetPageXenRemapped(pfn_to_page(PFN_DOWN(phys)));
> }
> memset(ret, 0, size);
> return ret;
> @@ -346,9 +346,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
> size, void *vaddr,
> /* Convert the size to actually allocated. */
> size = 1UL << (order + XEN_PAGE_SHIFT);
>
> - if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
> -range_straddles_page_boundary(phys, size)) &&
> - TestClearPageXenRemapped(virt_to_page(vaddr)))
> +#ifdef CONFIG_X86
> + if (WARN_ON(dev_addr + size - 1 > dma_mask) ||
> + range_straddles_page_boundary(phys, size)) {
> + return;
> + }
> +#endif
> +
> + if (TestClearPageXenRemapped(pfn_to_page(PFN_DOWN(phys
> xen_destroy_contiguous_region(phys, order);
>
> xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
Stefano, with your patch applied, I'm still getting:
[0.590705] Unable to handle kernel paging request at virtual
address fe000370
However, Boris' patch seems to get us much closer. It would be awesome if you
can take a look at that (plus the additional DMA issue that seems to
be dependent
on how much memory I allocate to Dom0).
Thanks,
Roman.
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, May 6, 2020 at 10:36 AM Boris Ostrovsky wrote: > > > On 5/6/20 12:14 PM, Nataliya Korovkina wrote: > > On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky > > wrote: > >> > >> On 5/6/20 9:08 AM, Nataliya Korovkina wrote: > >>> Hello, > >>> > >>> What I found out: rpi_firmware_property_list() allocates memory from > >>> dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page() > >>> is not eligible in this case. > >> > >> So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In > >> which case it has no business calling xen_swiotlb_free_coherent(). > >> > >> > >> -boris > >> > >> > >> > >> > > It does go. > > dma_alloc_coherent() indirectly calls xen_swiotlb_alloc_coherent(), > > then xen_alloc_coherent_pages() eventually calls arch_dma_alloc() in > > remap.c which successfully allocates pages from atomic pool. > > > Yes, I was looking at x86's implementation of xen_alloc_coherent_pages(). > > > > > > The patch Julien offered for domian_build.c moved Dom0 banks in the > > first G of RAM. > > So it covered the previous symptom (a crash during allocation) because > > now we avoid pathway when we mark a page "XenMapped". > > > > But the symptom still remains in xen_swiotlb_free_coherent() because > > "TestPage..." is called unconditionally. virt_to_page() is not > > applicable to such allocations. > > > Perhaps we just need to make sure we are using right virt-to-page > method. Something like > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index b6d2776..f224e69 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -335,6 +335,7 @@ int __ref xen_swiotlb_init(int verbose, bool early) > int order = get_order(size); > phys_addr_t phys; > u64 dma_mask = DMA_BIT_MASK(32); > + struct page *pg; > > if (hwdev && hwdev->coherent_dma_mask) > dma_mask = hwdev->coherent_dma_mask; > @@ -346,9 +347,12 @@ int __ref xen_swiotlb_init(int verbose, bool early) > /* Convert the size to actually allocated. */ > size = 1UL << (order + XEN_PAGE_SHIFT); > > + pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) : > virt_to_page(vaddr); > + BUG_ON(!pg); > + > if (!WARN_ON((dev_addr + size - 1 > dma_mask) || > range_straddles_page_boundary(phys, size)) && > - TestClearPageXenRemapped(virt_to_page(vaddr))) > + TestClearPageXenRemapped(pg)) > xen_destroy_contiguous_region(phys, order); > > xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, > attrs); > > > (I have not tested this at all) That's where I come in ;-) It appears that your patch gets us closest to a fully functional 5.6.x kernel under Xen on RPi4. Thank you so much for that! However, here's an interesting side-effect I'm now observing -- with your patch + original patch from Stefano (the one that only applies to include/xen/arm/page-coherent.h) I can now boot my RPi4 into a pretty functional system. However, it is only possible if I allocate 512M (or fewer) memory chunk to Dom0. If I try to go higher (820M for example) and all the way to 1G -- I start getting: [3.195851] mmc0: unrecognised SCR structure version 7 [3.200454] mmc0: error -22 whilst initialising SD card and my SD card stays offline. This is pretty reliable, and I guess is still related to some kind of a DMA issue perhaps? Thanks, Roman.
[xen-unstable-smoke test] 150059: tolerable all pass - PUSHED
flight 150059 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150059/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 8a6b1665d987d043c12dc723d758a7d2ca765264 baseline version: xen b58dc6dbfa3a038c5a22f06861a7652da80eca28 Last test of basis 150056 2020-05-06 10:00:41 Z0 days Testing same since 150059 2020-05-06 17:02:47 Z0 days1 attempts People who touched revisions under test: Roger Pau Monne Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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/xen.git b58dc6dbfa..8a6b1665d9 8a6b1665d987d043c12dc723d758a7d2ca765264 -> smoke
QEMU-Xen build failure
Hi all, on a recent checkout of the Xen staging source I ran into the following build error with QEMU upstream: tools/qemu-xen-dir-remote/slirp/src/ip_input.c:330:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] int delta = (char *)q - (m->m_flags & M_EXT ? m->m_ext : m->m_dat); Tamas
FuSa (temporary) repository for Xen safety documents
Hi all, I would like to let you know that I plan to create a FuSa.git repository under: https://gitlab.com/xen-project to host the work-in-progress Xen safety certification documents. The goal is to have those documents under xen.git, as they need to be linked to corresponding source code, but we opted for having a separate repository in the short term to allow easier access and contributions from safety experts that are not familiar with the git-send-email workflow. Cheers, Stefano
Re: [PATCH] x86/svm: Use flush-by-asid when available
On 06/05/2020 08:08, Roger Pau Monné wrote:
> On Tue, May 05, 2020 at 07:25:39PM +0100, Andrew Cooper wrote:
>> AMD Fam15h processors introduced the flush-by-asid feature, for more fine
>> grain flushing purposes.
>>
>> Flushing everything including ASID 0 (i.e. Xen context) is an an
>> unnecesserily
>> large hammer, and never necessary in the context of guest TLBs needing
>> invalidating.
>>
>> When available, use TLB_CTRL_FLUSH_ASID in preference to TLB_CTRL_FLUSH_ALL.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
>
> I should also look into restricting the usage of FLUSH_HVM_ASID_CORE
> and instead perform more fine grained per-vCPU flushes when possible,
> since FLUSH_HVM_ASID_CORE resets the pCPU ASID generation forcing a
> new ASID to be allocated for all vCPUs running on that pCPU.
>
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Monné
>>
>> The APM currently describes tlb_control encoding 1 as "Flush entire
>> TLB (Should be used only by legacy hypervisors.)". AMD have agreed that this
>> is misleading and should say "legacy hardware" instead.
> AFAICT using TLB_CTRL_FLUSH_ASID on hardware not supporting the
> feature has not been found to be safe? Ie: TLB_CTRL_FLUSH_ALL is a
> subset of TLB_CTRL_FLUSH_ASID from a bitmap PoV, so if those bits
> where ignored on older hardware it should be safe to unconditionally
> use it.
So as far as I can tell, TLB_CTRL_FLUSH_ASID is safe to use on older
hardware, but I was told in no uncertain terms by an AMD architect that
we can't rely on that.
Hence this patch not being s/TLB_CTRL_FLUSH_ALL/TLB_CTRL_FLUSH_ALL/ in
asid.c
>
>> This change does come with a minor observed perf improvement on Fam17h
>> hardware, of ~0.6s over ~22s for my XTF pagewalk test. This test will spot
>> TLB flushing issues, but isn't optimal for spotting the perf increase from
>> better flushing. There were no observed differences for Fam15h, but this
>> could simply mean that the measured code footprint was larger than the TLB on
>> this CPU.
>> ---
>> xen/arch/x86/hvm/svm/asid.c | 9 ++---
>> xen/include/asm-x86/hvm/svm/svm.h | 1 +
>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
>> index 9be90058c7..ab06dd3f3a 100644
>> --- a/xen/arch/x86/hvm/svm/asid.c
>> +++ b/xen/arch/x86/hvm/svm/asid.c
>> @@ -18,6 +18,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> void svm_asid_init(const struct cpuinfo_x86 *c)
>> {
>> @@ -47,15 +48,17 @@ void svm_asid_handle_vmrun(void)
>> if ( p_asid->asid == 0 )
>> {
>> vmcb_set_guest_asid(vmcb, 1);
>> -/* TODO: investigate using TLB_CTRL_FLUSH_ASID here instead. */
>> -vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
>> +vmcb->tlb_control =
>> +cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID :
>> TLB_CTRL_FLUSH_ALL;
>> return;
>> }
>>
>> if ( vmcb_get_guest_asid(vmcb) != p_asid->asid )
>> vmcb_set_guest_asid(vmcb, p_asid->asid);
>>
>> -vmcb->tlb_control = need_flush ? TLB_CTRL_FLUSH_ALL : TLB_CTRL_NO_FLUSH;
>> +vmcb->tlb_control =
>> +!need_flush ? TLB_CTRL_NO_FLUSH :
>> +cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
> Since this code structure is used in two places I would consider
> locally introducing something like:
>
> #define TLB_CTRL_FLUSH_CMD (cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID \
> : TLB_CTRL_FLUSH_ALL)
>
> To abstract it away.
Right, but TLB_CTRL_FLUSH_CMD is easy to confuse as constant in the same
space as TLB_CTRL_FLUSH_*, and the logic isn't going to survive a
conversion to a finer grain flushing in exactly this form.
~Andrew
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On 5/6/20 12:14 PM, Nataliya Korovkina wrote: > On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky > wrote: >> >> On 5/6/20 9:08 AM, Nataliya Korovkina wrote: >>> Hello, >>> >>> What I found out: rpi_firmware_property_list() allocates memory from >>> dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page() >>> is not eligible in this case. >> >> So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In >> which case it has no business calling xen_swiotlb_free_coherent(). >> >> >> -boris >> >> >> >> > It does go. > dma_alloc_coherent() indirectly calls xen_swiotlb_alloc_coherent(), > then xen_alloc_coherent_pages() eventually calls arch_dma_alloc() in > remap.c which successfully allocates pages from atomic pool. Yes, I was looking at x86's implementation of xen_alloc_coherent_pages(). > > The patch Julien offered for domian_build.c moved Dom0 banks in the > first G of RAM. > So it covered the previous symptom (a crash during allocation) because > now we avoid pathway when we mark a page "XenMapped". > > But the symptom still remains in xen_swiotlb_free_coherent() because > "TestPage..." is called unconditionally. virt_to_page() is not > applicable to such allocations. Perhaps we just need to make sure we are using right virt-to-page method. Something like diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index b6d2776..f224e69 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -335,6 +335,7 @@ int __ref xen_swiotlb_init(int verbose, bool early) int order = get_order(size); phys_addr_t phys; u64 dma_mask = DMA_BIT_MASK(32); + struct page *pg; if (hwdev && hwdev->coherent_dma_mask) dma_mask = hwdev->coherent_dma_mask; @@ -346,9 +347,12 @@ int __ref xen_swiotlb_init(int verbose, bool early) /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); + pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) : virt_to_page(vaddr); + BUG_ON(!pg); + if (!WARN_ON((dev_addr + size - 1 > dma_mask) || range_straddles_page_boundary(phys, size)) && - TestClearPageXenRemapped(virt_to_page(vaddr))) + TestClearPageXenRemapped(pg)) xen_destroy_contiguous_region(phys, order); xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs); (I have not tested this at all)
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, 6 May 2020, Nataliya Korovkina wrote:
> On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky
> wrote:
> >
> >
> > On 5/6/20 9:08 AM, Nataliya Korovkina wrote:
> > > Hello,
> > >
> > > What I found out: rpi_firmware_property_list() allocates memory from
> > > dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page()
> > > is not eligible in this case.
> >
> >
> > So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In
> > which case it has no business calling xen_swiotlb_free_coherent().
> >
> >
> > -boris
> >
> >
> >
> >
>
> It does go.
> dma_alloc_coherent() indirectly calls xen_swiotlb_alloc_coherent(),
> then xen_alloc_coherent_pages() eventually calls arch_dma_alloc() in
> remap.c which successfully allocates pages from atomic pool.
>
> The patch Julien offered for domian_build.c moved Dom0 banks in the
> first G of RAM.
> So it covered the previous symptom (a crash during allocation) because
> now we avoid pathway when we mark a page "XenMapped".
>
> But the symptom still remains in xen_swiotlb_free_coherent() because
> "TestPage..." is called unconditionally. virt_to_page() is not
> applicable to such allocations.
Ah! So this is the crux of the issue. I saw this kind of problem before
on ARM32 (in fact there are several comments warning not to use
virt_to_phys on ARM in drivers/xen/swiotlb-xen.c).
So, to recap we have 2 issues as far as I can tell:
- virt_to_page not working in some cases on ARM, leading to a crash
- WARN_ON for range_straddles_page_boundary which is normal on ARM
The appended patch addresses them by:
- using pfn_to_page instead virt_to_page
- moving the WARN_ON under a #ifdef (Juergen might have a better
suggestion on how to rework the WARN_ON)
Please let me know if this patch works!
Cheers,
Stefano
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b6d27762c6f8..0a40ac332a4c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -322,7 +322,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t
size,
xen_free_coherent_pages(hwdev, size, ret,
(dma_addr_t)phys, attrs);
return NULL;
}
- SetPageXenRemapped(virt_to_page(ret));
+ SetPageXenRemapped(pfn_to_page(PFN_DOWN(phys)));
}
memset(ret, 0, size);
return ret;
@@ -346,9 +346,14 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
size, void *vaddr,
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
- if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
-range_straddles_page_boundary(phys, size)) &&
- TestClearPageXenRemapped(virt_to_page(vaddr)))
+#ifdef CONFIG_X86
+ if (WARN_ON(dev_addr + size - 1 > dma_mask) ||
+ range_straddles_page_boundary(phys, size)) {
+ return;
+ }
+#endif
+
+ if (TestClearPageXenRemapped(pfn_to_page(PFN_DOWN(phys
xen_destroy_contiguous_region(phys, order);
xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, 6 May 2020, Jürgen Groß wrote: > On 06.05.20 00:34, Stefano Stabellini wrote: > > + Boris, Jürgen > > > > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is > > related to the recent xen dma_ops changes. Possibly the same thing > > reported by Peng here: > > > > https://marc.info/?l=linux-kernel=158805976230485=2 > > > > An in-depth analysis below. > > > > > > On Mon, 4 May 2020, Roman Shaposhnik wrote: > > > > > [2.534292] Unable to handle kernel paging request at virtual > > > > > address 0026c340 > > > > > [2.542373] Mem abort info: > > > > > [2.545257] ESR = 0x9604 > > > > > [2.548421] EC = 0x25: DABT (current EL), IL = 32 bits > > > > > [2.553877] SET = 0, FnV = 0 > > > > > [2.557023] EA = 0, S1PTW = 0 > > > > > [2.560297] Data abort info: > > > > > [2.563258] ISV = 0, ISS = 0x0004 > > > > > [2.567208] CM = 0, WnR = 0 > > > > > [2.570294] [0026c340] user address but active_mm is > > > > > swapper > > > > > [2.576783] Internal error: Oops: 9604 [#1] SMP > > > > > [2.581784] Modules linked in: > > > > > [2.584950] CPU: 3 PID: 135 Comm: kworker/3:1 Not tainted > > > > > 5.6.1-default #9 > > > > > [2.591970] Hardware name: Raspberry Pi 4 Model B (DT) > > > > > [2.597256] Workqueue: events deferred_probe_work_func > > > > > [2.602509] pstate: 6005 (nZCv daif -PAN -UAO) > > > > > [2.607431] pc : xen_swiotlb_free_coherent+0x198/0x1d8 > > > > > [2.612696] lr : dma_free_attrs+0x98/0xd0 > > > > > [2.616827] sp : 800011db3970 > > > > > [2.620242] x29: 800011db3970 x28: 000f7b00 > > > > > [2.625695] x27: 1000 x26: 37b68410 > > > > > [2.631129] x25: 0001 x24: f7b0 > > > > > [2.636583] x23: x22: > > > > > [2.642017] x21: 800011b0d000 x20: 80001179b548 > > > > > [2.647461] x19: 37b68410 x18: 0010 > > > > > [2.652905] x17: 35d66a00 x16: deadbeef > > > > > [2.658348] x15: x14: 80001179b548 > > > > > [2.663792] x13: 800091db37b7 x12: 800011db37bf > > > > > [2.669236] x11: 8000117c7000 x10: 800011db3740 > > > > > [2.674680] x9 : ffd0 x8 : 80001071e980 > > > > > [2.680124] x7 : 0132 x6 : 80001197a6ab > > > > > [2.685568] x5 : x4 : > > > > > [2.691012] x3 : f7b0 x2 : fde0 > > > > > [2.696465] x1 : 0026c340 x0 : 0246c340 > > > > > [2.701899] Call trace: > > > > > [2.704452] xen_swiotlb_free_coherent+0x198/0x1d8 > > > > > [2.709367] dma_free_attrs+0x98/0xd0 > > > > > [2.713143] rpi_firmware_property_list+0x1e4/0x240 > > > > > [2.718146] rpi_firmware_property+0x6c/0xb0 > > > > > [2.722535] rpi_firmware_probe+0xf0/0x1e0 > > > > > [2.726760] platform_drv_probe+0x50/0xa0 > > > > > [2.730879] really_probe+0xd8/0x438 > > > > > [2.734567] driver_probe_device+0xdc/0x130 > > > > > [2.738870] __device_attach_driver+0x88/0x108 > > > > > [2.743434] bus_for_each_drv+0x78/0xc8 > > > > > [2.747386] __device_attach+0xd4/0x158 > > > > > [2.751337] device_initial_probe+0x10/0x18 > > > > > [2.755649] bus_probe_device+0x90/0x98 > > > > > [2.759590] deferred_probe_work_func+0x88/0xd8 > > > > > [2.764244] process_one_work+0x1f0/0x3c0 > > > > > [2.768369] worker_thread+0x138/0x570 > > > > > [2.772234] kthread+0x118/0x120 > > > > > [2.775571] ret_from_fork+0x10/0x18 > > > > > [2.779263] Code: d34cfc00 f2dfbfe2 d37ae400 8b020001 (f8626800) > > > > > [2.785492] ---[ end trace 4c435212e349f45f ]--- > > > > > [2.793340] usb 1-1: New USB device found, idVendor=2109, > > > > > idProduct=3431, bcdDevice= 4.20 > > > > > [2.801038] usb 1-1: New USB device strings: Mfr=0, Product=1, > > > > > SerialNumber=0 > > > > > [2.808297] usb 1-1: Product: USB2.0 Hub > > > > > [2.813710] hub 1-1:1.0: USB hub found > > > > > [2.817117] hub 1-1:1.0: 4 ports detected > > > > > > > > > > This is bailing out right here: > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/firmware/raspberrypi.c?h=v5.6.1#n125 > > > > > > > > > > FYIW (since I modified the source to actually print what was returned > > > > > right before it bails) we get: > > > > > buf[1] == 0x80004 > > > > > buf[2] == 0x0001 > > > > > > > > > > Status 0x80004 is of course suspicious since it is not even listed > > > > > here: > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/soc/bcm2835/raspberrypi-firmware.h#n14 > > > > > > > > > > So it appears that this DMA request path is somehow busted and it > > > > > would be really nice to figure out why. > > > > > > > > You have
RE: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, 6 May 2020, Peng Fan wrote: > > Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU > > > > On 06.05.20 00:34, Stefano Stabellini wrote: > > > + Boris, Jürgen > > > > > > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is > > > related to the recent xen dma_ops changes. Possibly the same thing > > > reported by Peng here: > > Yes. It is same issue. > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc > > > .info%2F%3Fl%3Dlinux-kernel%26m%3D158805976230485%26w%3D2 > > p;data=02% > > > > > 7C01%7Cpeng.fan%40nxp.com%7Cab98b2db94484141a8ad08d7f1803372%7 > > C686ea1d > > > > > 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637243405233572354sd > > ata=0Yr5h > > > Rg4%2FuApsBpTwIIL4StZU%2FUA55oP5Lfnfmtj4Hg%3Dreserved=0 > > > > > > An in-depth analysis below. > > > > > > > > > On Mon, 4 May 2020, Roman Shaposhnik wrote: > > [2.534292] Unable to handle kernel paging request at virtual > > address 0026c340 > > [2.542373] Mem abort info: > > [2.545257] ESR = 0x9604 > > [2.548421] EC = 0x25: DABT (current EL), IL = 32 bits > > [2.553877] SET = 0, FnV = 0 > > [2.557023] EA = 0, S1PTW = 0 > > [2.560297] Data abort info: > > [2.563258] ISV = 0, ISS = 0x0004 > > [2.567208] CM = 0, WnR = 0 > > [2.570294] [0026c340] user address but active_mm is > > swapper > > [2.576783] Internal error: Oops: 9604 [#1] SMP > > [2.581784] Modules linked in: > > [2.584950] CPU: 3 PID: 135 Comm: kworker/3:1 Not tainted > > 5.6.1-default #9 > > [2.591970] Hardware name: Raspberry Pi 4 Model B (DT) > > [2.597256] Workqueue: events deferred_probe_work_func > > [2.602509] pstate: 6005 (nZCv daif -PAN -UAO) > > [2.607431] pc : xen_swiotlb_free_coherent+0x198/0x1d8 > > [2.612696] lr : dma_free_attrs+0x98/0xd0 > > [2.616827] sp : 800011db3970 > > [2.620242] x29: 800011db3970 x28: 000f7b00 > > [2.625695] x27: 1000 x26: 37b68410 > > [2.631129] x25: 0001 x24: f7b0 > > [2.636583] x23: x22: > > [2.642017] x21: 800011b0d000 x20: 80001179b548 > > [2.647461] x19: 37b68410 x18: 0010 > > [2.652905] x17: 35d66a00 x16: deadbeef > > [2.658348] x15: x14: 80001179b548 > > [2.663792] x13: 800091db37b7 x12: 800011db37bf > > [2.669236] x11: 8000117c7000 x10: 800011db3740 > > [2.674680] x9 : ffd0 x8 : 80001071e980 > > [2.680124] x7 : 0132 x6 : 80001197a6ab > > [2.685568] x5 : x4 : > > [2.691012] x3 : f7b0 x2 : fde0 > > [2.696465] x1 : 0026c340 x0 : 0246c340 > > [2.701899] Call trace: > > [2.704452] xen_swiotlb_free_coherent+0x198/0x1d8 > > [2.709367] dma_free_attrs+0x98/0xd0 > > [2.713143] rpi_firmware_property_list+0x1e4/0x240 > > [2.718146] rpi_firmware_property+0x6c/0xb0 > > [2.722535] rpi_firmware_probe+0xf0/0x1e0 > > [2.726760] platform_drv_probe+0x50/0xa0 > > [2.730879] really_probe+0xd8/0x438 > > [2.734567] driver_probe_device+0xdc/0x130 > > [2.738870] __device_attach_driver+0x88/0x108 > > [2.743434] bus_for_each_drv+0x78/0xc8 > > [2.747386] __device_attach+0xd4/0x158 > > [2.751337] device_initial_probe+0x10/0x18 > > [2.755649] bus_probe_device+0x90/0x98 > > [2.759590] deferred_probe_work_func+0x88/0xd8 > > [2.764244] process_one_work+0x1f0/0x3c0 > > [2.768369] worker_thread+0x138/0x570 > > [2.772234] kthread+0x118/0x120 > > [2.775571] ret_from_fork+0x10/0x18 > > [2.779263] Code: d34cfc00 f2dfbfe2 d37ae400 8b020001 > > (f8626800) > > [2.785492] ---[ end trace 4c435212e349f45f ]--- > > [2.793340] usb 1-1: New USB device found, idVendor=2109, > > idProduct=3431, bcdDevice= 4.20 > > [2.801038] usb 1-1: New USB device strings: Mfr=0, Product=1, > > SerialNumber=0 > > [2.808297] usb 1-1: Product: USB2.0 Hub > > [2.813710] hub 1-1:1.0: USB hub found > > [2.817117] hub 1-1:1.0: 4 ports detected > > > > This is bailing out right here: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > > it.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.g > > > > it%2Ftree%2Fdrivers%2Ffirmware%2Fraspberrypi.c%3Fh%3Dv5.6.1%23n125 > > & > > > > amp;data=02%7C01%7Cpeng.fan%40nxp.com%7Cab98b2db94484141a8ad0 > > 8d7f18 > > > >
[PATCH] libxl: update libxlu_disk_l.[ch]
Use flex 2.6.4 that is shipped in Debian Buster. Signed-off-by: Wei Liu --- Do this because Roger posted a patch to fix clang build, which requires updating the same files. I don't want bury his changes in unrelated ones. --- tools/libxl/libxlu_disk_l.c | 867 ++-- tools/libxl/libxlu_disk_l.h | 474 +--- 2 files changed, 947 insertions(+), 394 deletions(-) diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c index 944990732b0b..b0ac3a865a61 100644 --- a/tools/libxl/libxlu_disk_l.c +++ b/tools/libxl/libxlu_disk_l.c @@ -1,10 +1,7 @@ #line 2 "libxlu_disk_l.c" -#line 31 "libxlu_disk_l.l" #include "libxl_osdeps.h" /* must come before any other headers */ - - -#line 8 "libxlu_disk_l.c" +#line 5 "libxlu_disk_l.c" #define YY_INT_ALIGNED short int @@ -12,12 +9,222 @@ #define FLEX_SCANNER #define YY_FLEX_MAJOR_VERSION 2 -#define YY_FLEX_MINOR_VERSION 5 -#define YY_FLEX_SUBMINOR_VERSION 39 +#define YY_FLEX_MINOR_VERSION 6 +#define YY_FLEX_SUBMINOR_VERSION 4 #if YY_FLEX_SUBMINOR_VERSION > 0 #define FLEX_BETA #endif +#ifdef yy_create_buffer +#define xlu__disk_yy_create_buffer_ALREADY_DEFINED +#else +#define yy_create_buffer xlu__disk_yy_create_buffer +#endif + +#ifdef yy_delete_buffer +#define xlu__disk_yy_delete_buffer_ALREADY_DEFINED +#else +#define yy_delete_buffer xlu__disk_yy_delete_buffer +#endif + +#ifdef yy_scan_buffer +#define xlu__disk_yy_scan_buffer_ALREADY_DEFINED +#else +#define yy_scan_buffer xlu__disk_yy_scan_buffer +#endif + +#ifdef yy_scan_string +#define xlu__disk_yy_scan_string_ALREADY_DEFINED +#else +#define yy_scan_string xlu__disk_yy_scan_string +#endif + +#ifdef yy_scan_bytes +#define xlu__disk_yy_scan_bytes_ALREADY_DEFINED +#else +#define yy_scan_bytes xlu__disk_yy_scan_bytes +#endif + +#ifdef yy_init_buffer +#define xlu__disk_yy_init_buffer_ALREADY_DEFINED +#else +#define yy_init_buffer xlu__disk_yy_init_buffer +#endif + +#ifdef yy_flush_buffer +#define xlu__disk_yy_flush_buffer_ALREADY_DEFINED +#else +#define yy_flush_buffer xlu__disk_yy_flush_buffer +#endif + +#ifdef yy_load_buffer_state +#define xlu__disk_yy_load_buffer_state_ALREADY_DEFINED +#else +#define yy_load_buffer_state xlu__disk_yy_load_buffer_state +#endif + +#ifdef yy_switch_to_buffer +#define xlu__disk_yy_switch_to_buffer_ALREADY_DEFINED +#else +#define yy_switch_to_buffer xlu__disk_yy_switch_to_buffer +#endif + +#ifdef yypush_buffer_state +#define xlu__disk_yypush_buffer_state_ALREADY_DEFINED +#else +#define yypush_buffer_state xlu__disk_yypush_buffer_state +#endif + +#ifdef yypop_buffer_state +#define xlu__disk_yypop_buffer_state_ALREADY_DEFINED +#else +#define yypop_buffer_state xlu__disk_yypop_buffer_state +#endif + +#ifdef yyensure_buffer_stack +#define xlu__disk_yyensure_buffer_stack_ALREADY_DEFINED +#else +#define yyensure_buffer_stack xlu__disk_yyensure_buffer_stack +#endif + +#ifdef yylex +#define xlu__disk_yylex_ALREADY_DEFINED +#else +#define yylex xlu__disk_yylex +#endif + +#ifdef yyrestart +#define xlu__disk_yyrestart_ALREADY_DEFINED +#else +#define yyrestart xlu__disk_yyrestart +#endif + +#ifdef yylex_init +#define xlu__disk_yylex_init_ALREADY_DEFINED +#else +#define yylex_init xlu__disk_yylex_init +#endif + +#ifdef yylex_init_extra +#define xlu__disk_yylex_init_extra_ALREADY_DEFINED +#else +#define yylex_init_extra xlu__disk_yylex_init_extra +#endif + +#ifdef yylex_destroy +#define xlu__disk_yylex_destroy_ALREADY_DEFINED +#else +#define yylex_destroy xlu__disk_yylex_destroy +#endif + +#ifdef yyget_debug +#define xlu__disk_yyget_debug_ALREADY_DEFINED +#else +#define yyget_debug xlu__disk_yyget_debug +#endif + +#ifdef yyset_debug +#define xlu__disk_yyset_debug_ALREADY_DEFINED +#else +#define yyset_debug xlu__disk_yyset_debug +#endif + +#ifdef yyget_extra +#define xlu__disk_yyget_extra_ALREADY_DEFINED +#else +#define yyget_extra xlu__disk_yyget_extra +#endif + +#ifdef yyset_extra +#define xlu__disk_yyset_extra_ALREADY_DEFINED +#else +#define yyset_extra xlu__disk_yyset_extra +#endif + +#ifdef yyget_in +#define xlu__disk_yyget_in_ALREADY_DEFINED +#else +#define yyget_in xlu__disk_yyget_in +#endif + +#ifdef yyset_in +#define xlu__disk_yyset_in_ALREADY_DEFINED +#else +#define yyset_in xlu__disk_yyset_in +#endif + +#ifdef yyget_out +#define xlu__disk_yyget_out_ALREADY_DEFINED +#else +#define yyget_out xlu__disk_yyget_out +#endif + +#ifdef yyset_out +#define xlu__disk_yyset_out_ALREADY_DEFINED +#else +#define yyset_out xlu__disk_yyset_out +#endif + +#ifdef yyget_leng +#define xlu__disk_yyget_leng_ALREADY_DEFINED +#else +#define yyget_leng xlu__disk_yyget_leng +#endif + +#ifdef yyget_text +#define xlu__disk_yyget_text_ALREADY_DEFINED +#else +#define yyget_text xlu__disk_yyget_text +#endif + +#ifdef yyget_lineno +#define xlu__disk_yyget_lineno_ALREADY_DEFINED +#else +#define yyget_lineno xlu__disk_yyget_lineno +#endif + +#ifdef yyset_lineno +#define xlu__disk_yyset_lineno_ALREADY_DEFINED +#else +#define yyset_lineno
Re: [PATCH] x86/svm: Clean up vmcbcleanbits_t handling
On 06/05/2020 16:10, Jan Beulich wrote:
> On 05.05.2020 19:32, Andrew Cooper wrote:
>> @@ -435,17 +435,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
>> struct cpu_user_regs *regs)
>> ASSERT(n2vmcb != NULL);
>>
>> /* Check if virtual VMCB cleanbits are valid */
>> -vcleanbits_valid = 1;
>> -if ( svm->ns_ovvmcb_pa == INVALID_PADDR )
>> -vcleanbits_valid = 0;
>> -if (svm->ns_ovvmcb_pa != nv->nv_vvmcxaddr)
>> -vcleanbits_valid = 0;
>> -
>> -#define vcleanbit_set(_name)\
>> -(vcleanbits_valid && ns_vmcb->cleanbits.fields._name)
>> +if ( svm->ns_ovvmcb_pa != INVALID_PADDR &&
>> + svm->ns_ovvmcb_pa != nv->nv_vvmcxaddr )
>> +clean = ns_vmcb->cleanbits;
> It looks to me as if the proper inversion of the original condition
> would mean == on the right side of &&, not != .
Oops, yes. Fixed.
>
>> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
>> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
>> @@ -384,34 +384,21 @@ typedef union
>>
>> typedef union
>> {
>> -uint32_t bytes;
>> -struct
>> -{
>> -/* cr_intercepts, dr_intercepts, exception_intercepts,
>> - * general{1,2}_intercepts, pause_filter_count, tsc_offset */
>> -uint32_t intercepts: 1;
>> -/* iopm_base_pa, msrpm_base_pa */
>> -uint32_t iopm: 1;
>> -/* guest_asid */
>> -uint32_t asid: 1;
>> -/* vintr */
>> -uint32_t tpr: 1;
>> -/* np_enable, h_cr3, g_pat */
>> -uint32_t np: 1;
>> -/* cr0, cr3, cr4, efer */
>> -uint32_t cr: 1;
>> -/* dr6, dr7 */
>> -uint32_t dr: 1;
>> -/* gdtr, idtr */
>> -uint32_t dt: 1;
>> -/* cs, ds, es, ss, cpl */
>> -uint32_t seg: 1;
>> -/* cr2 */
>> -uint32_t cr2: 1;
>> -/* debugctlmsr, last{branch,int}{to,from}ip */
>> -uint32_t lbr: 1;
>> -uint32_t resv: 21;
>> -} fields;
>> +struct {
>> +bool intercepts:1; /* 0: cr/dr/exception/general1/2_intercepts,
>> +* pause_filter_count, tsc_offset */
> Could I talk you into omitting the 1/2 part, as there's going to
> be a 3 for at least MCOMMIT? Just "general" ought to be clear
> enough, I would think.
Can do. I'm not overly happy about this spilling onto two lines, but I
can't think of how to usefully shrink the comment further without losing
information.
~Andrew
RE: [PATCH v2 1/5] xen/common: introduce a new framework for save/restore of 'domain' context
> -Original Message-
> From: Jan Beulich
> Sent: 29 April 2020 12:02
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; Volodymyr Babchuk
> ; Roger
> Pau Monné
> Subject: Re: [PATCH v2 1/5] xen/common: introduce a new framework for
> save/restore of 'domain' context
>
> On 07.04.2020 19:38, Paul Durrant wrote:
> > +void __init domain_register_save_type(unsigned int tc, const char *name,
> > + bool per_vcpu,
> > + domain_save_handler save,
> > + domain_load_handler load)
> > +{
> > +BUG_ON(tc > ARRAY_SIZE(handlers));
>
> >=
Yes.
>
> > +ASSERT(!handlers[tc].save);
> > +ASSERT(!handlers[tc].load);
> > +
> > +handlers[tc].name = name;
> > +handlers[tc].per_vcpu = per_vcpu;
> > +handlers[tc].save = save;
> > +handlers[tc].load = load;
> > +}
> > +
> > +int domain_save_begin(struct domain_context *c, unsigned int tc,
> > + const char *name, const struct vcpu *v, size_t len)
>
> I find it quite odd for a function like this one to take a
> struct vcpu * rather than a struct domain *. See also below
> comment on the vcpu_id field in the public header.
I guess struct domain + vcpu_id can be used.
>
> > +{
> > +int rc;
> > +
> > +if ( c->log )
> > +gdprintk(XENLOG_INFO, "%pv save: %s (%lu)\n", v, name,
> > + (unsigned long)len);
> > +
> > +BUG_ON(tc != c->desc.typecode);
> > +BUG_ON(v->vcpu_id != c->desc.vcpu_id);
> > +
> > +ASSERT(!c->data_len);
> > +c->data_len = c->desc.length = len;
> > +
> > +rc = c->copy.write(c->priv, >desc, sizeof(c->desc));
> > +if ( rc )
> > +return rc;
> > +
> > +c->desc.length = 0;
> > +
> > +return 0;
> > +}
> > +
> > +int domain_save_data(struct domain_context *c, const void *src, size_t len)
> > +{
> > +if ( c->desc.length + len > c->data_len )
> > +return -ENOSPC;
> > +
> > +c->desc.length += len;
> > +
> > +return c->copy.write(c->priv, src, len);
> > +}
> > +
> > +int domain_save_end(struct domain_context *c)
>
> I'm sure there is a reason for the split into three load/save
> functions (begin/data/end), but I can't figure it and the
> description also doesn't explain it. They're all used together
> only afaics, in domain_{save,load}_entry(). Or wait, there are
> DOMAIN_{SAVE,LOAD}_BEGIN() macros apparently allowing separate
> use of ..._begin(), but then it's still not clear why ..._end()
> need to be separate from ..._data().
The split is to avoid the need to double-buffer in the save code, shared info
being a case in point. If the entire save record needs to be written in one
call then the shared info content would need to be copied into a newly
allocated save record and then copied again into the aggregate context buffer.
>
> > +int domain_save(struct domain *d, domain_write_entry write, void *priv,
> > +bool dry_run)
> > +{
> > +struct domain_context c = {
> > +.copy.write = write,
> > +.priv = priv,
> > +.log = !dry_run,
> > +};
> > +struct domain_save_header h = {
>
> const? Perhaps even static?
>
Ok, static is a good idea.
> > +.magic = DOMAIN_SAVE_MAGIC,
> > +.version = DOMAIN_SAVE_VERSION,
> > +};
> > +struct domain_save_header e;
> > +unsigned int i;
> > +int rc;
> > +
> > +ASSERT(d != current->domain);
> > +
> > +if ( d->is_dying )
> > +return -EINVAL;
>
> Could I talk you into using less generic an error code here, e.g.
> -ESRCH or -ENXIO? There look to be further uses of EINVAL that
> may want replacing.
>
I'm going to drop this check as it creates a problem for live update, where we
actually do need to extract and restore state for dying domains.
> > +domain_pause(d);
> > +
> > +c.desc.typecode = DOMAIN_SAVE_CODE(HEADER);
> > +
> > +rc = DOMAIN_SAVE_ENTRY(HEADER, , d->vcpu[0], , sizeof(h));
> > +if ( rc )
> > +goto out;
> > +
> > +for ( i = 0; i < ARRAY_SIZE(handlers); i++ )
> > +{
> > +domain_save_handler save = handlers[i].save;
> > +
> > +if ( !save )
> > +continue;
> > +
> > +memset(, 0, sizeof(c.desc));
> > +c.desc.typecode = i;
> > +
> > +if ( handlers[i].per_vcpu )
> > +{
> > +struct vcpu *v;
> > +
> > +for_each_vcpu ( d, v )
> > +{
> > +c.desc.vcpu_id = v->vcpu_id;
> > +
> > +rc = save(v, , dry_run);
> > +if ( rc )
> > +goto out;
> > +}
> > +}
> > +else
> > +{
> > +rc = save(d->vcpu[0], , dry_run);
> > +if ( rc )
> > +goto out;
> > +}
> > +}
> > +
> > +memset(, 0,
Re: [PATCH v18 1/2] tools/libxc: add VM forking functions
On Wed, May 06, 2020 at 06:41:43AM -0700, Tamas K Lengyel wrote: > Add functions to issue VM forking hypercalls > > Signed-off-by: Tamas K Lengyel Acked-by: Wei Liu
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Wed, May 6, 2020 at 9:43 AM Boris Ostrovsky wrote: > > > On 5/6/20 9:08 AM, Nataliya Korovkina wrote: > > Hello, > > > > What I found out: rpi_firmware_property_list() allocates memory from > > dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page() > > is not eligible in this case. > > > So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In > which case it has no business calling xen_swiotlb_free_coherent(). > > > -boris > > > > It does go. dma_alloc_coherent() indirectly calls xen_swiotlb_alloc_coherent(), then xen_alloc_coherent_pages() eventually calls arch_dma_alloc() in remap.c which successfully allocates pages from atomic pool. The patch Julien offered for domian_build.c moved Dom0 banks in the first G of RAM. So it covered the previous symptom (a crash during allocation) because now we avoid pathway when we mark a page "XenMapped". But the symptom still remains in xen_swiotlb_free_coherent() because "TestPage..." is called unconditionally. virt_to_page() is not applicable to such allocations. Thanks, Nataliya
[xen-4.11-testing test] 150040: tolerable FAIL - PUSHED
flight 150040 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150040/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab baseline version: xen 96a8b5bc48be2ae9691369849036453f8850135b Last test of basis 149701 2020-04-17 12:06:32 Z 19 days Testing same since 150040 2020-05-05 16:06:51 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Juergen Gross Wei Liu jobs: build-amd64-xsm
[PATCH] xen/sched: always modify vcpu pause flags atomically
credit2 is currently modifying the pause flags of vcpus non-atomically
via sched_set_pause_flags() and sched_clear_pause_flags(). This is
dangerous as there are cases where the paus flags are modified without
any lock held.
So drop the non-atomic pause flag modification functions and rename the
atomic ones dropping the _atomic suffix.
Fixes: a76255b4266516 ("xen/sched: make credit2 scheduler vcpu agnostic.")
Signed-off-by: Juergen Gross
---
It should be noted that this issue wasn't introduced by core scheduling
as even before credit2 was using the non-atomic __set_bit() and
__clear_bit() variants.
---
xen/common/sched/credit.c | 4 ++--
xen/common/sched/private.h | 22 +-
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 93d89da278..d0aa017c64 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -453,7 +453,7 @@ static inline void __runq_tickle(const struct csched_unit
*new)
SCHED_UNIT_STAT_CRANK(cur, kicked_away);
SCHED_UNIT_STAT_CRANK(cur, migrate_r);
SCHED_STAT_CRANK(migrate_kicked_away);
-sched_set_pause_flags_atomic(cur->unit, _VPF_migrating);
+sched_set_pause_flags(cur->unit, _VPF_migrating);
}
/* Tickle cpu anyway, to let new preempt cur. */
SCHED_STAT_CRANK(tickled_busy_cpu);
@@ -973,7 +973,7 @@ csched_unit_acct(struct csched_private *prv, unsigned int
cpu)
{
SCHED_UNIT_STAT_CRANK(svc, migrate_r);
SCHED_STAT_CRANK(migrate_running);
-sched_set_pause_flags_atomic(currunit, _VPF_migrating);
+sched_set_pause_flags(currunit, _VPF_migrating);
/*
* As we are about to tickle cpu, we should clear its bit in
* idlers. But, if we are here, it means there is someone running
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 367811a12f..b9a5b4c01c 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -172,7 +172,7 @@ static inline void sched_set_pause_flags(struct sched_unit
*unit,
struct vcpu *v;
for_each_sched_unit_vcpu ( unit, v )
-__set_bit(bit, >pause_flags);
+set_bit(bit, >pause_flags);
}
/* Clear a bit in pause_flags of all vcpus of a unit. */
@@ -181,26 +181,6 @@ static inline void sched_clear_pause_flags(struct
sched_unit *unit,
{
struct vcpu *v;
-for_each_sched_unit_vcpu ( unit, v )
-__clear_bit(bit, >pause_flags);
-}
-
-/* Set a bit in pause_flags of all vcpus of a unit via atomic updates. */
-static inline void sched_set_pause_flags_atomic(struct sched_unit *unit,
-unsigned int bit)
-{
-struct vcpu *v;
-
-for_each_sched_unit_vcpu ( unit, v )
-set_bit(bit, >pause_flags);
-}
-
-/* Clear a bit in pause_flags of all vcpus of a unit via atomic updates. */
-static inline void sched_clear_pause_flags_atomic(struct sched_unit *unit,
- unsigned int bit)
-{
-struct vcpu *v;
-
for_each_sched_unit_vcpu ( unit, v )
clear_bit(bit, >pause_flags);
}
--
2.26.1
Re: [PATCH] x86/svm: Clean up vmcbcleanbits_t handling
On 05.05.2020 19:32, Andrew Cooper wrote:
> @@ -435,17 +435,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
> struct cpu_user_regs *regs)
> ASSERT(n2vmcb != NULL);
>
> /* Check if virtual VMCB cleanbits are valid */
> -vcleanbits_valid = 1;
> -if ( svm->ns_ovvmcb_pa == INVALID_PADDR )
> -vcleanbits_valid = 0;
> -if (svm->ns_ovvmcb_pa != nv->nv_vvmcxaddr)
> -vcleanbits_valid = 0;
> -
> -#define vcleanbit_set(_name) \
> -(vcleanbits_valid && ns_vmcb->cleanbits.fields._name)
> +if ( svm->ns_ovvmcb_pa != INVALID_PADDR &&
> + svm->ns_ovvmcb_pa != nv->nv_vvmcxaddr )
> +clean = ns_vmcb->cleanbits;
It looks to me as if the proper inversion of the original condition
would mean == on the right side of &&, not != .
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -384,34 +384,21 @@ typedef union
>
> typedef union
> {
> -uint32_t bytes;
> -struct
> -{
> -/* cr_intercepts, dr_intercepts, exception_intercepts,
> - * general{1,2}_intercepts, pause_filter_count, tsc_offset */
> -uint32_t intercepts: 1;
> -/* iopm_base_pa, msrpm_base_pa */
> -uint32_t iopm: 1;
> -/* guest_asid */
> -uint32_t asid: 1;
> -/* vintr */
> -uint32_t tpr: 1;
> -/* np_enable, h_cr3, g_pat */
> -uint32_t np: 1;
> -/* cr0, cr3, cr4, efer */
> -uint32_t cr: 1;
> -/* dr6, dr7 */
> -uint32_t dr: 1;
> -/* gdtr, idtr */
> -uint32_t dt: 1;
> -/* cs, ds, es, ss, cpl */
> -uint32_t seg: 1;
> -/* cr2 */
> -uint32_t cr2: 1;
> -/* debugctlmsr, last{branch,int}{to,from}ip */
> -uint32_t lbr: 1;
> -uint32_t resv: 21;
> -} fields;
> +struct {
> +bool intercepts:1; /* 0: cr/dr/exception/general1/2_intercepts,
> +* pause_filter_count, tsc_offset */
Could I talk you into omitting the 1/2 part, as there's going to
be a 3 for at least MCOMMIT? Just "general" ought to be clear
enough, I would think.
Jan
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
Hi, On 06/05/2020 14:48, Corey Minyard wrote: On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote: Hi, On 02/05/2020 03:16, Corey Minyard wrote: On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote: On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote: On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote: Hi! I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock, upstream kernel. The kernel itself works perfectly well on the board. When I try booting it as Dom0 under Xen, it goes into a stacktrace (attached). Getting Xen working on the Pi4 requires a lot of moving parts, and they all have to be right. Tell me about it! It is a pretty frustrating journey to align everything just right. On the other hand -- it seems worth to enable RPi as an ARM development platform for Xen given how ubiquitous it is. Hence me trying to combine pristine upstream kernel (5.6.1) with pristine upstream Xen to enable 100% upstream developer workflow on RPi. Looking at what nice folks over at Dornerworks have previously done to make RPi kernels boot as Dom0 I've come across these 3 patches: https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux The first patch seems irrelevant (unless I'm missing something really basic here). It might be irrelevant for your configuration, assuming that Xen gets the right information from EFI. I haven't tried EFI booting. I'd doing a bit of belt-and-suspenders strategy really -- I'm actually using UEFI u-boot implementation that pre-populates device trees and then I'm also forcing an extra copy of it to be load explicitly via the GRUB devicetree command (GRUB runs as a UEFI payload). I also have access to the semi-official TianoCore RPi4 port that seems to be working pretty well: https://github.com/pftf/RPi4/releases/tag/v1.5 for booting all sort of UEFI payloads on RPi4. The 2nd patch applied with no issue (but I don't think it is related) but the 3d patch failed to apply on account of 5.6.1 kernel no longer having: dev->archdata.dev_dma_ops E.g. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55 I've tried to emulate the effect of the patch by simply introducing a static variable that would signal that we already initialized dev->dma_ops -- but that didn't help at all. I'm CCing Jeff Kubascik to see if the original authors of that Corey Minyard to see if may be they have any suggestions on how this may be dealt with. Any advice would be greatly appreciated! What's your Pi4 config.txt file look like? The GIC is not being handled correctly, and I'm guessing that configuration is wrong. You can't use the stock config.txt file with Xen, you have to modify the configuration a bit. Understood. I'm actually using a custom one: https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/config.txt I could swear that I had a GIC setting in it -- but apparently no -- so I added the following at the top of what you could see at the URL above: total_mem=4096 enable_gic=1 I think just adding: enable_gic=1 total_mem=1024 Right -- but my board has 4G memory -- so I think what I did above should work. Nope. If you say 4096M of RAM, your issue is almost certainly DMA, but it's not (just) the Linux code. On the Raspberry Pi 4, several devices cannot DMA to above 1024M of RAM, but Xen does not handle this. The 1024M of RAM is a limitation you will have to live with until Xen has a fix. IIUC, dom0 would need to have some memory below 1GB for this to work, am I correct? FYI, this also seems to fix the issue with HDMI not working. Thank you for the testing! I will have a look how I can properly upstream this fix (I think we want to keep 4GB limit for other platforms). Cheers, -- Julien Grall
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On Sat, May 02, 2020 at 12:46:14PM +0100, Julien Grall wrote:
> Hi,
>
> On 02/05/2020 03:16, Corey Minyard wrote:
> > On Fri, May 01, 2020 at 06:06:11PM -0700, Roman Shaposhnik wrote:
> > > On Fri, May 1, 2020 at 4:42 AM Corey Minyard wrote:
> > > >
> > > > On Thu, Apr 30, 2020 at 07:20:05PM -0700, Roman Shaposhnik wrote:
> > > > > Hi!
> > > > >
> > > > > I'm trying to run Xen on Raspberry Pi 4 with 5.6.1 stock,
> > > > > upstream kernel. The kernel itself works perfectly well
> > > > > on the board. When I try booting it as Dom0 under Xen,
> > > > > it goes into a stacktrace (attached).
> > > >
> > > > Getting Xen working on the Pi4 requires a lot of moving parts, and they
> > > > all have to be right.
> > >
> > > Tell me about it! It is a pretty frustrating journey to align
> > > everything just right.
> > > On the other hand -- it seems worth to enable RPi as an ARM development
> > > platform for Xen given how ubiquitous it is.
> > >
> > > Hence me trying to combine pristine upstream kernel (5.6.1) with
> > > pristine upstream
> > > Xen to enable 100% upstream developer workflow on RPi.
> > >
> > > > > Looking at what nice folks over at Dornerworks have previously
> > > > > done to make RPi kernels boot as Dom0 I've come across these
> > > > > 3 patches:
> > > > >
> > > > > https://github.com/dornerworks/xen-rpi4-builder/tree/master/patches/linux
> > > > >
> > > > > The first patch seems irrelevant (unless I'm missing something
> > > > > really basic here).
> > > >
> > > > It might be irrelevant for your configuration, assuming that Xen gets
> > > > the right information from EFI. I haven't tried EFI booting.
> > >
> > > I'd doing a bit of belt-and-suspenders strategy really -- I'm actually
> > > using UEFI u-boot implementation that pre-populates device trees
> > > and then I'm also forcing an extra copy of it to be load explicitly
> > > via the GRUB devicetree command (GRUB runs as a UEFI payload).
> > >
> > > I also have access to the semi-official TianoCore RPi4 port that seems
> > > to be working pretty well: https://github.com/pftf/RPi4/releases/tag/v1.5
> > > for booting all sort of UEFI payloads on RPi4.
> > >
> > > > > The 2nd patch applied with no issue (but
> > > > > I don't think it is related) but the 3d patch failed to apply on
> > > > > account of 5.6.1 kernel no longer having:
> > > > > dev->archdata.dev_dma_ops
> > > > > E.g.
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/mm/dma-mapping.c?h=v5.6.1#n55
> > > > >
> > > > > I've tried to emulate the effect of the patch by simply introducing
> > > > > a static variable that would signal that we already initialized
> > > > > dev->dma_ops -- but that didn't help at all.
> > > > >
> > > > > I'm CCing Jeff Kubascik to see if the original authors of that Corey
> > > > > Minyard
> > > > > to see if may be they have any suggestions on how this may be dealt
> > > > > with.
> > > > >
> > > > > Any advice would be greatly appreciated!
> > > >
> > > > What's your Pi4 config.txt file look like? The GIC is not being handled
> > > > correctly, and I'm guessing that configuration is wrong. You can't use
> > > > the stock config.txt file with Xen, you have to modify the
> > > > configuration a
> > > > bit.
> > >
> > > Understood. I'm actually using a custom one:
> > > https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/config.txt
> > >
> > > I could swear that I had a GIC setting in it -- but apparently no -- so
> > > I added the following at the top of what you could see at the URL above:
> > >
> > > total_mem=4096
> > > enable_gic=1
> > >
> > > > I think just adding:
> > > >
> > > > enable_gic=1
> > > > total_mem=1024
> > >
> > > Right -- but my board has 4G memory -- so I think what I did above should
> > > work.
> >
> > Nope. If you say 4096M of RAM, your issue is almost certainly DMA, but
> > it's not (just) the Linux code. On the Raspberry Pi 4, several devices
> > cannot DMA to above 1024M of RAM, but Xen does not handle this. The
> > 1024M of RAM is a limitation you will have to live with until Xen has a
> > fix.
>
> IIUC, dom0 would need to have some memory below 1GB for this to work, am I
> correct?
FYI, this also seems to fix the issue with HDMI not working.
-corey
>
> If so could you try the following patch?
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 430708753642..002f49dba74b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -282,7 +282,7 @@ static void __init allocate_memory_11(struct domain *d,
> */
> while ( order >= min_low_order )
> {
> -for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
> +for ( bits = order ; bits <= (lowmem ? 30 : PADDR_BITS); bits++ )
> {
> pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
> if ( pg != NULL )
> @@ -313,7 +313,7 @@ static void
[PATCH v18 2/2] tools/libxl: VM forking toolstack side
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
docs/man/xl.1.pod.in | 49 +
tools/libxl/libxl.h | 12 ++
tools/libxl/libxl_create.c | 359 ---
tools/libxl/libxl_dm.c | 2 +-
tools/libxl/libxl_dom.c | 43 -
tools/libxl/libxl_internal.h | 7 +
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_x86.c | 42
tools/xl/Makefile| 2 +-
tools/xl/xl.h| 5 +
tools/xl/xl_cmdtable.c | 15 ++
tools/xl/xl_forkvm.c | 149 +++
tools/xl/xl_vmcontrol.c | 14 ++
13 files changed, 535 insertions(+), 165 deletions(-)
create mode 100644 tools/xl/xl_forkvm.c
diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..67b4e8588a 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,55 @@ above).
=back
+=item B [I] I
+
+Create a fork of a running VM. The domain will be paused after the operation
+and remains paused while forks of it exist. Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware. The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or
max_event_channels.
+
+B
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model. Currently required
when
+launching the device model. Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.
Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork. Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=item B<--allow-iommu>
+
+Specify to allow forking a domain that has IOMMU enabled. Only compatible with
+forks using --launch-dm no.
+
+=back
+
=item B [I]
Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..4bbb0a773d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,18 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx,
libxl_psr_feat_type type,
unsigned int lvl, unsigned int *nr,
libxl_psr_hw_info **info);
void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned int nr);
+
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t max_vcpus,
+ bool allow_with_iommu, uint32_t *domid)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+uint32_t domid,
+const libxl_asyncprogress_how *aop_console_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid)
+LIBXL_EXTERNAL_CALLERS_ONLY;
#endif
/* misc */
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 5a043df15f..1a930c2de7 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,12 +538,12 @@ out:
return ret;
}
-int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
- libxl__domain_build_state *state,
- uint32_t *domid, bool soft_reset)
+static int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config
*d_config,
+ libxl__domain_build_state *state,
+ uint32_t domid)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
-int ret, rc, nb_vm;
+int rc, nb_vm;
const char *dom_type;
char *uuid_string;
char *dom_path, *vm_path, *libxl_path;
@@ -555,9 +555,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
*d_config,
/* convenience aliases */
libxl_domain_create_info *info = _config->c_info;
-libxl_domain_build_info *b_info = _config->b_info;
-
-assert(soft_reset || *domid == INVALID_DOMID);
uuid_string = libxl__uuid2string(gc, info->uuid);
if (!uuid_string) {
@@
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
On 5/6/20 9:08 AM, Nataliya Korovkina wrote: > Hello, > > What I found out: rpi_firmware_property_list() allocates memory from > dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page() > is not eligible in this case. So then it seems it didn't go through xen_swiotlb_alloc_coherent(). In which case it has no business calling xen_swiotlb_free_coherent(). -boris
[PATCH v18 1/2] tools/libxc: add VM forking functions
Add functions to issue VM forking hypercalls
Signed-off-by: Tamas K Lengyel
---
tools/libxc/include/xenctrl.h | 14 ++
tools/libxc/xc_memshr.c | 26 ++
2 files changed, 40 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5f25c5a6d4..0a6ff93229 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2232,6 +2232,20 @@ int xc_memshr_range_share(xc_interface *xch,
uint64_t first_gfn,
uint64_t last_gfn);
+int xc_memshr_fork(xc_interface *xch,
+ uint32_t source_domain,
+ uint32_t client_domain,
+ bool allow_with_iommu);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
/* Debug calls: return the number of pages referencing the shared frame backing
* the input argument. Should be one or greater.
*
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..2300cc7075 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,32 @@ int xc_memshr_debug_gref(xc_interface *xch,
return xc_memshr_memop(xch, domid, );
}
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid,
+ bool allow_with_iommu)
+{
+xen_mem_sharing_op_t mso;
+
+memset(, 0, sizeof(mso));
+
+mso.op = XENMEM_sharing_op_fork;
+mso.u.fork.parent_domain = pdomid;
+
+if ( allow_with_iommu )
+mso.u.fork.flags |= XENMEM_FORK_WITH_IOMMU_ALLOWED;
+
+return xc_memshr_memop(xch, domid, );
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+xen_mem_sharing_op_t mso;
+
+memset(, 0, sizeof(mso));
+mso.op = XENMEM_sharing_op_fork_reset;
+
+return xc_memshr_memop(xch, domid, );
+}
+
int xc_memshr_audit(xc_interface *xch)
{
xen_mem_sharing_op_t mso;
--
2.25.1
Re: [PATCH v17 2/2] xen/tools: VM forking toolstack side
On Wed, May 6, 2020 at 7:00 AM Wei Liu wrote: > > On Fri, May 01, 2020 at 07:59:45AM -0600, Tamas K Lengyel wrote: > > On Thu, Apr 23, 2020 at 9:33 AM Tamas K Lengyel > > wrote: > > > > > > Add necessary bits to implement "xl fork-vm" commands. The command allows > > > the > > > user to specify how to launch the device model allowing for a late-launch > > > model > > > in which the user can execute the fork without the device model and > > > decide to > > > only later launch it. > > > > > > Signed-off-by: Tamas K Lengyel > > > > Patch ping. If nothing else at least the libxc parts would be nice to > > get merged before the freeze. > > Changes to libxc looks good to me. > > Please split it out to a patch with proper commit message. > Sounds good, will do. Thanks, Tamas
Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
Hello, What I found out: rpi_firmware_property_list() allocates memory from dma_atomic_pool which was mapped to VMALLOC region, so virt_to_page() is not eligible in this case. Thanks, Nataliya On Wed, May 6, 2020 at 4:57 AM Peng Fan wrote: > > > Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU > > > > On 06.05.20 00:34, Stefano Stabellini wrote: > > > + Boris, Jürgen > > > > > > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is > > > related to the recent xen dma_ops changes. Possibly the same thing > > > reported by Peng here: > > Yes. It is same issue. > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc > > > .info%2F%3Fl%3Dlinux-kernel%26m%3D158805976230485%26w%3D2 > > p;data=02% > > > > > 7C01%7Cpeng.fan%40nxp.com%7Cab98b2db94484141a8ad08d7f1803372%7 > > C686ea1d > > > > > 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637243405233572354sd > > ata=0Yr5h > > > Rg4%2FuApsBpTwIIL4StZU%2FUA55oP5Lfnfmtj4Hg%3Dreserved=0 > > > > > > An in-depth analysis below. > > > > > > > > > On Mon, 4 May 2020, Roman Shaposhnik wrote: > > [2.534292] Unable to handle kernel paging request at virtual > > address 0026c340 > > [2.542373] Mem abort info: > > [2.545257] ESR = 0x9604 > > [2.548421] EC = 0x25: DABT (current EL), IL = 32 bits > > [2.553877] SET = 0, FnV = 0 > > [2.557023] EA = 0, S1PTW = 0 > > [2.560297] Data abort info: > > [2.563258] ISV = 0, ISS = 0x0004 > > [2.567208] CM = 0, WnR = 0 > > [2.570294] [0026c340] user address but active_mm is > > swapper > > [2.576783] Internal error: Oops: 9604 [#1] SMP > > [2.581784] Modules linked in: > > [2.584950] CPU: 3 PID: 135 Comm: kworker/3:1 Not tainted > > 5.6.1-default #9 > > [2.591970] Hardware name: Raspberry Pi 4 Model B (DT) > > [2.597256] Workqueue: events deferred_probe_work_func > > [2.602509] pstate: 6005 (nZCv daif -PAN -UAO) > > [2.607431] pc : xen_swiotlb_free_coherent+0x198/0x1d8 > > [2.612696] lr : dma_free_attrs+0x98/0xd0 > > [2.616827] sp : 800011db3970 > > [2.620242] x29: 800011db3970 x28: 000f7b00 > > [2.625695] x27: 1000 x26: 37b68410 > > [2.631129] x25: 0001 x24: f7b0 > > [2.636583] x23: x22: > > [2.642017] x21: 800011b0d000 x20: 80001179b548 > > [2.647461] x19: 37b68410 x18: 0010 > > [2.652905] x17: 35d66a00 x16: deadbeef > > [2.658348] x15: x14: 80001179b548 > > [2.663792] x13: 800091db37b7 x12: 800011db37bf > > [2.669236] x11: 8000117c7000 x10: 800011db3740 > > [2.674680] x9 : ffd0 x8 : 80001071e980 > > [2.680124] x7 : 0132 x6 : 80001197a6ab > > [2.685568] x5 : x4 : > > [2.691012] x3 : f7b0 x2 : fde0 > > [2.696465] x1 : 0026c340 x0 : 0246c340 > > [2.701899] Call trace: > > [2.704452] xen_swiotlb_free_coherent+0x198/0x1d8 > > [2.709367] dma_free_attrs+0x98/0xd0 > > [2.713143] rpi_firmware_property_list+0x1e4/0x240 > > [2.718146] rpi_firmware_property+0x6c/0xb0 > > [2.722535] rpi_firmware_probe+0xf0/0x1e0 > > [2.726760] platform_drv_probe+0x50/0xa0 > > [2.730879] really_probe+0xd8/0x438 > > [2.734567] driver_probe_device+0xdc/0x130 > > [2.738870] __device_attach_driver+0x88/0x108 > > [2.743434] bus_for_each_drv+0x78/0xc8 > > [2.747386] __device_attach+0xd4/0x158 > > [2.751337] device_initial_probe+0x10/0x18 > > [2.755649] bus_probe_device+0x90/0x98 > > [2.759590] deferred_probe_work_func+0x88/0xd8 > > [2.764244] process_one_work+0x1f0/0x3c0 > > [2.768369] worker_thread+0x138/0x570 > > [2.772234] kthread+0x118/0x120 > > [2.775571] ret_from_fork+0x10/0x18 > > [2.779263] Code: d34cfc00 f2dfbfe2 d37ae400 8b020001 > > (f8626800) > > [2.785492] ---[ end trace 4c435212e349f45f ]--- > > [2.793340] usb 1-1: New USB device found, idVendor=2109, > > idProduct=3431, bcdDevice= 4.20 > > [2.801038] usb 1-1: New USB device strings: Mfr=0, Product=1, > > SerialNumber=0 > > [2.808297] usb 1-1: Product: USB2.0 Hub > > [2.813710] hub 1-1:1.0: USB hub found > > [2.817117] hub 1-1:1.0: 4 ports detected > > > > This is bailing out right here: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > > it.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.g > > > >
Re: [PATCH 2/3] configure: also add EXTRA_PREFIX to {CPP/LD}FLAGS
On Tue, May 05, 2020 at 11:24:53AM +0200, Roger Pau Monne wrote: > The path provided by EXTRA_PREFIX should be added to the search path > of the configure script, like it's done in Config.mk. Not doing so > makes the search path for configure differ from the search path used > by the build. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu
Re: [PATCH 3/3] tools/libxl: disable clang indentation check for the disk parser
On Tue, May 05, 2020 at 11:24:54AM +0200, Roger Pau Monne wrote: > Clang 10 complains with: > > 13: error: misleading indentation; statement is not part of the previous 'if' > [-Werror,-Wmisleading-indentation] > if ( ! yyg->yy_state_buf ) > ^ > libxlu_disk_l.c:1259:9: note: previous statement is here > if ( ! yyg->yy_state_buf ) > ^ > > Due to the missing braces in single line statements and the wrong > indentation. Fix this by disabling the warning for that specific file. > I haven't found a way to force flex to add braces around single line > statements in conditional blocks. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu
Re: [PATCH v17 2/2] xen/tools: VM forking toolstack side
On Fri, May 01, 2020 at 07:59:45AM -0600, Tamas K Lengyel wrote: > On Thu, Apr 23, 2020 at 9:33 AM Tamas K Lengyel > wrote: > > > > Add necessary bits to implement "xl fork-vm" commands. The command allows > > the > > user to specify how to launch the device model allowing for a late-launch > > model > > in which the user can execute the fork without the device model and decide > > to > > only later launch it. > > > > Signed-off-by: Tamas K Lengyel > > Patch ping. If nothing else at least the libxc parts would be nice to > get merged before the freeze. Changes to libxc looks good to me. Please split it out to a patch with proper commit message. Wei.
[xen-unstable-smoke test] 150056: tolerable all pass - PUSHED
flight 150056 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150056/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen b58dc6dbfa3a038c5a22f06861a7652da80eca28 baseline version: xen 779efdbb502b38c66b774b124fa0ceed254875bd Last test of basis 150049 2020-05-05 20:00:32 Z0 days Testing same since 150056 2020-05-06 10:00:41 Z0 days1 attempts People who touched revisions under test: Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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/xen.git 779efdbb50..b58dc6dbfa b58dc6dbfa3a038c5a22f06861a7652da80eca28 -> smoke
Re: [PATCH] xenbus: avoid stack overflow warning
On Wed, May 6, 2020 at 7:12 AM Jürgen Groß wrote: > > On 05.05.20 22:57, Arnd Bergmann wrote: > > On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote: > >> On 05.05.20 17:01, Arnd Bergmann wrote: > >>> On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote: > On 05.05.20 16:15, Arnd Bergmann wrote: > >>> > >>> I considered that as well, and don't really mind either way. I think it > >>> does > >>> get a bit ugly whatever we do. If you prefer the union, I can respin the > >>> patch that way. > >> > >> Hmm, thinking more about it I think the real clean solution would be to > >> extend struct map_ring_valloc_hvm to cover the pv case, too, to add the > >> map and unmap arrays (possibly as a union) to it and to allocate it > >> dynamically instead of having it on the stack. > >> > >> Would you be fine doing this? > > > > This is a little more complex than I'd want to do without doing any testing > > (and no, I don't want to do the testing either) ;-) > > > > It does sound like a better approach though. > > I take this as you are fine with me writing the patch and adding you as > "Reported-by:"? Yes, definitely. Thanks! Arnd
[xen-unstable-coverity test] 150055: all pass - PUSHED
flight 150055 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/150055/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 779efdbb502b38c66b774b124fa0ceed254875bd baseline version: xen 0135be8bd8cd60090298f02310691b688d95c3a8 Last test of basis 149910 2020-05-03 09:19:24 Z3 days Testing same since 150055 2020-05-06 09:19:00 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ashok Raj Borislav Petkov Hongyan Xia Ian Jackson Jan Beulich Roger Pau Monné Thomas Gleixner Wei Liu jobs: coverity-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/xen.git 0135be8bd8..779efdbb50 779efdbb502b38c66b774b124fa0ceed254875bd -> coverity-tested/smoke
[xen-4.13-testing test] 150042: tolerable trouble: fail/pass/starved - PUSHED
flight 150042 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150042/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149836 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 149836 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen d2aecd86c4481291b260869c47cf0a9a02321564 baseline version: xen 35b80b2a011416383466f21e32cb72cf73df491b Last test of basis 149836 2020-04-27 13:36:20 Z8 days Testing same since 150042 2020-05-05 16:06:37 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Jan Beulich Juergen Gross Julien Grall Marek Marczykowski-Górecki Michael Young Sander Eikelenboom Stefano Stabellini Wei Liu YOUNG,
[PATCH v4] sched: print information about scheduling granularity
Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.
Note: per-cpupool granularity selection is not implemented yet. Every
cpupool gets its granularity from the single global value.
Take this opportunity to introduce struct sched_gran_name array and
refactor sched_select_granularity().
Signed-off-by: Sergey Dyasli
---
v4:
- use char[8]
v3:
- use const char*
- use sched_gran_name array instead of switch
- updated commit message
v2:
- print information on a separate line
- use per-cpupool granularity
- updated commit message
CC: Juergen Gross
CC: Dario Faggioli
CC: George Dunlap
CC: Jan Beulich
---
xen/common/sched/cpupool.c | 51 +++---
1 file changed, 42 insertions(+), 9 deletions(-)
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index d40345b585..97c2d5b3c1 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -40,19 +40,50 @@ static DEFINE_SPINLOCK(cpupool_lock);
static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
static unsigned int __read_mostly sched_granularity = 1;
+struct sched_gran_name {
+enum sched_gran mode;
+char name[8];
+};
+
+static const struct sched_gran_name sg_name[] = {
+{SCHED_GRAN_cpu, "cpu"},
+{SCHED_GRAN_core, "core"},
+{SCHED_GRAN_socket, "socket"},
+};
+
+static void sched_gran_print(enum sched_gran mode, unsigned int gran)
+{
+const char *name = "";
+unsigned int i;
+
+for ( i = 0; i < ARRAY_SIZE(sg_name); i++ )
+{
+if ( mode == sg_name[i].mode )
+{
+name = sg_name[i].name;
+break;
+}
+}
+
+printk("Scheduling granularity: %s, %u CPU%s per sched-resource\n",
+ name, gran, gran == 1 ? "" : "s");
+}
+
#ifdef CONFIG_HAS_SCHED_GRANULARITY
static int __init sched_select_granularity(const char *str)
{
-if ( strcmp("cpu", str) == 0 )
-opt_sched_granularity = SCHED_GRAN_cpu;
-else if ( strcmp("core", str) == 0 )
-opt_sched_granularity = SCHED_GRAN_core;
-else if ( strcmp("socket", str) == 0 )
-opt_sched_granularity = SCHED_GRAN_socket;
-else
-return -EINVAL;
+unsigned int i;
-return 0;
+for ( i = 0; i < ARRAY_SIZE(sg_name); i++ )
+{
+if ( strcmp(sg_name[i].name, str) == 0 )
+{
+opt_sched_granularity = sg_name[i].mode;
+return 0;
+}
+}
+
+return -EINVAL;
}
custom_param("sched-gran", sched_select_granularity);
#endif
@@ -115,6 +146,7 @@ static void __init cpupool_gran_init(void)
warning_add(fallback);
sched_granularity = gran;
+sched_gran_print(opt_sched_granularity, sched_granularity);
}
unsigned int cpupool_get_granularity(const struct cpupool *c)
@@ -911,6 +943,7 @@ void dump_runq(unsigned char key)
{
printk("Cpupool %d:\n", (*c)->cpupool_id);
printk("Cpus: %*pbl\n", CPUMASK_PR((*c)->cpu_valid));
+sched_gran_print((*c)->gran, cpupool_get_granularity(*c));
schedule_dump(*c);
}
--
2.17.1
Re: [PATCH 1/2] xen/Kconfig: define EXPERT a bool rather than a string
Hi Jan, On 30/04/2020 15:32, Jan Beulich wrote: On 30.04.2020 14:43, Julien Grall wrote: From: Julien Grall Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT can only have two values (enabled or disabled). So switch from a string to a bool. Take the opportunity to replace all "EXPERT = y" to "EXPERT". Signed-off-by: Julien Grall Acked-by: Jan Beulich with a remark: --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -33,7 +33,7 @@ source "arch/Kconfig" config ACPI bool - prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT = "y" + prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT depends on ARM_64 ---help--- @@ -51,7 +51,7 @@ config GICV3 config HAS_ITS bool -prompt "GICv3 ITS MSI controller support" if EXPERT = "y" +prompt "GICv3 ITS MSI controller support" if EXPERT depends on GICV3 && !NEW_VGIC Could I talk you info switching ones like the above (looks like there aren't further ones) to ... @@ -81,7 +81,7 @@ config SBSA_VUART_CONSOLE SBSA Generic UART implements a subset of ARM PL011 UART. config ARM_SSBD - bool "Speculative Store Bypass Disable" if EXPERT = "y" + bool "Speculative Store Bypass Disable" if EXPERT ... this more compact form on this occasion? I will do the switch on commit if there are no more comment. Cheers, -- Julien Grall
Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the menuconfig directly
Hi George, On 04/05/2020 12:10, George Dunlap wrote: On Apr 30, 2020, at 3:50 PM, Jan Beulich wrote: In order to make easier to experiment, the option EXPERT can now be selected from the menuconfig rather than make command line. This does not change the fact a kernel with EXPERT mode selected will not be security supported. Well, if I'm not mis-remembering it was on purpose to make it more difficult for people to declare themselves "experts". FAOD I'm not meaning to imply I don't see and accept the frustration aspect you mention further up. The two need to be carefully weighed against one another. I don’t think we need to make it difficult for people to declare themselves experts, particularly as “all” it means at the moment is, “Can build something which is not security supported”. People who are building their own hypervisors are already pretty well advanced; I think we can let them shoot themselves in the foot if they want to. Assuming I reword the commit message regarding "make clean", could I consider this as an acked-by? Cheers, -- Julien Grall
Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected from the menuconfig directly
Hi Ian,
On 04/05/2020 13:34, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be selected
from the menuconfig directly"):
On Apr 30, 2020, at 3:50 PM, Jan Beulich wrote:
Well, if I'm not mis-remembering it was on purpose to make it more
difficult for people to declare themselves "experts". FAOD I'm not
meaning to imply I don't see and accept the frustration aspect you
mention further up. The two need to be carefully weighed against
one another.
Yes, it was on purpose. However, I had my doubts at the time and
I think experience has shown that this was a mistake.
I don’t think we need to make it difficult for people to declare
themselves experts, particularly as “all” it means at the moment is,
“Can build something which is not security supported”. People who
are building their own hypervisors are already pretty well advanced;
I think we can let them shoot themselves in the foot if they want
to.
Precisely.
Can I consider this as an Acked-by? :)
Cheers,
--
Julien Grall
Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
Hi Jan,
On 05/05/2020 07:26, Jan Beulich wrote:
On 22.04.2020 10:26, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
Further
- do_physdev_op_compat() didn't use the param form for its parameter,
- {hap,shadow}_track_dirty_vram() wrongly used the param form,
- compat processor Px logic failed to check compatibility of native and
compat structures not further converted.
As this eliminates all users of guest_handle_from_param() and as there's
no real need to allow for conversions in both directions, drop the
macros as well.
Signed-off-by: Jan Beulich
[...]
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -492,7 +492,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
return ret;
}
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
Nit: switch to uint32_t while there?
Reviewed-by: Roger Pau Monné
Unless I hear objections, I'm intending to commit this then in a
day or two with the suggested change made and the R-b given. Of
course a formally required ack for the Arm side dropping of
guest_handle_from_param() would still be nice ...
I missed the small change on Arm sorry:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Re: [PATCH] Arm: fix build with CONFIG_DTB_FILE set
On 06/05/2020 10:36, Jan Beulich wrote:
Recent changes no longer allow modification of AFLAGS. The needed
conversion was apparently missed in 2740d96efdd3 ("xen/build: have the
root Makefile generates the CFLAGS").
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -68,7 +68,7 @@ extra-y += $(TARGET_SUBARCH)/head.o
ifdef CONFIG_DTB_FILE
obj-y += dtb.o
-AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
endif
ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
--
Julien Grall
Re: [PATCH] x86/hyperv: stash and use the configured max VP index
On Thu, Apr 30, 2020 at 12:21:18PM +0200, Roger Pau Monné wrote:
> On Thu, Apr 30, 2020 at 12:15:58PM +0200, Roger Pau Monné wrote:
> > On Wed, Apr 29, 2020 at 11:47:18AM +, Wei Liu wrote:
> > > On Wed, Apr 29, 2020 at 11:41:44AM +0100, Wei Liu wrote:
> > > > The value returned from CPUID is the maximum number for virtual
> > > > processors supported by Hyper-V. It could be larger than the maximum
> > > > number of virtual processors configured.
> > > >
> > > > Stash the configured number into a variable and use it in calculations.
> > > >
> > > > Signed-off-by: Wei Liu
> > > > ---
> > > > xen/arch/x86/guest/hyperv/hyperv.c | 4
> > > > xen/arch/x86/guest/hyperv/private.h | 1 +
> > > > xen/arch/x86/guest/hyperv/tlb.c | 2 +-
> > > > xen/arch/x86/guest/hyperv/util.c| 2 +-
> > > > 4 files changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> > > > b/xen/arch/x86/guest/hyperv/hyperv.c
> > > > index 91a6782cd986..84221b751453 100644
> > > > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > > > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > > > @@ -33,6 +33,7 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> > > > DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> > > > DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
> > > >
> > > > +unsigned int __read_mostly hv_max_vp_index;
> > > > static bool __read_mostly hcall_page_ready;
> > > >
> > > > static uint64_t generate_guest_id(void)
> > > > @@ -143,6 +144,9 @@ static int setup_hypercall_pcpu_arg(void)
> > > > rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
> > > > this_cpu(hv_vp_index) = vp_index_msr;
> > > >
> > > > +if ( vp_index_msr > hv_max_vp_index )
> > > > +hv_max_vp_index = vp_index_msr;
> > > > +
> > > > return 0;
> > > > }
> > > >
> > > > diff --git a/xen/arch/x86/guest/hyperv/private.h
> > > > b/xen/arch/x86/guest/hyperv/private.h
> > > > index 354fc7f685a7..fea3e291e944 100644
> > > > --- a/xen/arch/x86/guest/hyperv/private.h
> > > > +++ b/xen/arch/x86/guest/hyperv/private.h
> > > > @@ -28,6 +28,7 @@
> > > > DECLARE_PER_CPU(void *, hv_input_page);
> > > > DECLARE_PER_CPU(void *, hv_vp_assist);
> > > > DECLARE_PER_CPU(unsigned int, hv_vp_index);
> > > > +extern unsigned int hv_max_vp_index;
> > > >
> > > > static inline unsigned int hv_vp_index(unsigned int cpu)
> > > > {
> > > > diff --git a/xen/arch/x86/guest/hyperv/tlb.c
> > > > b/xen/arch/x86/guest/hyperv/tlb.c
> > > > index 1d723d6ee679..0a44071481bd 100644
> > > > --- a/xen/arch/x86/guest/hyperv/tlb.c
> > > > +++ b/xen/arch/x86/guest/hyperv/tlb.c
> > > > @@ -166,7 +166,7 @@ int hyperv_flush_tlb(const cpumask_t *mask, const
> > > > void *va,
> > > > {
> > > > unsigned int vpid = hv_vp_index(cpu);
> > > >
> > > > -if ( vpid >= ms_hyperv.max_vp_index )
> > > > +if ( vpid >= hv_max_vp_index )
> > >
> > > I think the >= should be changed to > here.
> >
> > I agree. With this fixed:
> >
> > Reviewed-by: Roger Pau Monné
>
> FWIW, I think it should also be nice to add an ASSERT_UNREACHABLE in
> the if body, as now it shouldn't be possible for vpid to be greater
> than hv_max_vp_index unless something has gone really wrong?
At some point I will initialise vpid to (uint32_t)-1 so it could go over
hv_max_vp_index if there is a bug in code.
Wei.
>
> Roger.
[PATCH] Arm: fix build with CONFIG_DTB_FILE set
Recent changes no longer allow modification of AFLAGS. The needed
conversion was apparently missed in 2740d96efdd3 ("xen/build: have the
root Makefile generates the CFLAGS").
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -68,7 +68,7 @@ extra-y += $(TARGET_SUBARCH)/head.o
ifdef CONFIG_DTB_FILE
obj-y += dtb.o
-AFLAGS += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
+AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\"
endif
ALL_OBJS := $(TARGET_SUBARCH)/head.o $(ALL_OBJS)
Re: [PATCH v3] tools/xenstore: don't store domU's mfn of ring page in xenstored
On Thu, Apr 30, 2020 at 07:38:42AM +0200, Juergen Gross wrote: > The XS_INTRODUCE command has two parameters: the mfn (or better: gfn) > of the domain's xenstore ring page and the event channel of the > domain for communicating with Xenstore. > > The gfn is not really needed. It is stored in the per-domain struct > in xenstored and in case of another XS_INTRODUCE for the domain it > is tested to match the original value. If it doesn't match the > command is aborted via EINVAL, otherwise the event channel to the > domain is recreated. > > As XS_INTRODUCE is limited to dom0 and there is no real downside of > recreating the event channel just omit the test for the gfn to > match and don't return EINVAL for multiple XS_INTRODUCE calls. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: [PATCH] x86/svm: Clean up vmcbcleanbits_t handling
On Tue, May 05, 2020 at 06:32:50PM +0100, Andrew Cooper wrote: > Rework the vmcbcleanbits_t definitons to use bool, drop 'fields' from the > namespace, position the comments in an unambiguous position, and include the > bit position. > > In svm_vmexit_handler(), don't bother conditionally writing ~0 or 0 based on > hardware support. The field was entirely unused and ignored on older > hardware (and we're already setting reserved cleanbits anyway). > > In nsvm_vmcb_prepare4vmrun(), simplify the logic massivly by dropping the ^e > vcleanbit_set() macro using a vmcbcleanbits_t local variable which only gets > filled in the case that clean bits were valid previously. Fix up the style on > impacted lines. > > No practical change in behaviour. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 5950e4d52b..aeebeaf873 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -345,7 +345,7 @@ static int svm_vmcb_restore(struct vcpu *v, struct > hvm_hw_cpu *c) > else > vmcb->event_inj.raw = 0; > > -vmcb->cleanbits.bytes = 0; > +vmcb->cleanbits.raw = 0; > paging_update_paging_modes(v); > > return 0; > @@ -693,12 +693,12 @@ static void svm_set_segment_register(struct vcpu *v, > enum x86_segment seg, > case x86_seg_ds: > case x86_seg_es: > case x86_seg_ss: /* cpl */ > -vmcb->cleanbits.fields.seg = 0; > +vmcb->cleanbits.seg = 0; > break; > > case x86_seg_gdtr: > case x86_seg_idtr: > -vmcb->cleanbits.fields.dt = 0; > +vmcb->cleanbits.dt = 0; Nit: using false here (and above) would be better, since the fields are now booleans. Thanks, Roger.
[ANNOUNCE] Call for agenda items for 7 May Community Call @ 15:00 UTC
Hi all, The proposed agenda is in and https://cryptpad.fr/pad/#/2/pad/edit/qPQUEQEv3nJJ97clS8b2KdtP/ you can edit to add items. Alternatively, you can reply to this mail directly. Agenda items appreciated a few days before the call: please put your name besides items if you edit the document. Note the following administrative conventions for the call: * Unless, agreed in the pervious meeting otherwise, the call is on the 1st Thursday of each month at 1600 British Time (either GMT or BST) * I usually send out a meeting reminder a few days before with a provisional agenda * If you want to be CC'ed please add or remove yourself from the sign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ Best Regards George == Dial-in Information == ## Meeting time 15:00 - 16:00 UTC (during BST) Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020=5=7=15=0=0=1234=37=224=179 ## Dial in details Web: https://www.gotomeet.me/GeorgeDunlap You can also dial in using your phone. Access Code: 168-682-109 China (Toll Free): 4008 811084 Germany: +49 692 5736 7317 Poland (Toll Free): 00 800 1124759 Ukraine (Toll Free): 0 800 50 1733 United Kingdom: +44 330 221 0088 United States: +1 (571) 317-3129 Spain: +34 932 75 2004 More phone numbers Australia: +61 2 9087 3604 Austria: +43 7 2081 5427 Argentina (Toll Free): 0 800 444 3375 Bahrain (Toll Free): 800 81 111 Belarus (Toll Free): 8 820 0011 0400 Belgium: +32 28 93 7018 Brazil (Toll Free): 0 800 047 4906 Bulgaria (Toll Free): 00800 120 4417 Canada: +1 (647) 497-9391 Chile (Toll Free): 800 395 150 Colombia (Toll Free): 01 800 518 4483 Czech Republic (Toll Free): 800 500448 Denmark: +45 32 72 03 82 Finland: +358 923 17 0568 France: +33 170 950 594 Greece (Toll Free): 00 800 4414 3838 Hong Kong (Toll Free): 30713169906-886-965 Hungary (Toll Free): (06) 80 986 255 Iceland (Toll Free): 800 7204 India (Toll Free): 18002669272 Indonesia (Toll Free): 007 803 020 5375 Ireland: +353 15 360 728 Israel (Toll Free): 1 809 454 830 Italy: +39 0 247 92 13 01 Japan (Toll Free): 0 120 663 800 Korea, Republic of (Toll Free): 00798 14 207 4914 Luxembourg (Toll Free): 800 85158 Malaysia (Toll Free): 1 800 81 6854 Mexico (Toll Free): 01 800 522 1133 Netherlands: +31 207 941 377 New Zealand: +64 9 280 6302 Norway: +47 21 93 37 51 Panama (Toll Free): 00 800 226 7928 Peru (Toll Free): 0 800 77023 Philippines (Toll Free): 1 800 1110 1661 Portugal (Toll Free): 800 819 575 Romania (Toll Free): 0 800 410 029 Russian Federation (Toll Free): 8 800 100 6203 Saudi Arabia (Toll Free): 800 844 3633 Singapore (Toll Free): 18007231323 South Africa (Toll Free): 0 800 555 447 Sweden: +46 853 527 827 Switzerland: +41 225 4599 78 Taiwan (Toll Free): 0 800 666 854 Thailand (Toll Free): 001 800 011 023 Turkey (Toll Free): 00 800 4488 23683 United Arab Emirates (Toll Free): 800 044 40439 Uruguay (Toll Free): 0004 019 1018 Viet Nam (Toll Free): 122 80 481 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check
RE: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU
> Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU > > On 06.05.20 00:34, Stefano Stabellini wrote: > > + Boris, Jürgen > > > > See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is > > related to the recent xen dma_ops changes. Possibly the same thing > > reported by Peng here: Yes. It is same issue. > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarc > > .info%2F%3Fl%3Dlinux-kernel%26m%3D158805976230485%26w%3D2 > p;data=02% > > > 7C01%7Cpeng.fan%40nxp.com%7Cab98b2db94484141a8ad08d7f1803372%7 > C686ea1d > > > 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637243405233572354sd > ata=0Yr5h > > Rg4%2FuApsBpTwIIL4StZU%2FUA55oP5Lfnfmtj4Hg%3Dreserved=0 > > > > An in-depth analysis below. > > > > > > On Mon, 4 May 2020, Roman Shaposhnik wrote: > [2.534292] Unable to handle kernel paging request at virtual > address 0026c340 > [2.542373] Mem abort info: > [2.545257] ESR = 0x9604 > [2.548421] EC = 0x25: DABT (current EL), IL = 32 bits > [2.553877] SET = 0, FnV = 0 > [2.557023] EA = 0, S1PTW = 0 > [2.560297] Data abort info: > [2.563258] ISV = 0, ISS = 0x0004 > [2.567208] CM = 0, WnR = 0 > [2.570294] [0026c340] user address but active_mm is > swapper > [2.576783] Internal error: Oops: 9604 [#1] SMP > [2.581784] Modules linked in: > [2.584950] CPU: 3 PID: 135 Comm: kworker/3:1 Not tainted > 5.6.1-default #9 > [2.591970] Hardware name: Raspberry Pi 4 Model B (DT) > [2.597256] Workqueue: events deferred_probe_work_func > [2.602509] pstate: 6005 (nZCv daif -PAN -UAO) > [2.607431] pc : xen_swiotlb_free_coherent+0x198/0x1d8 > [2.612696] lr : dma_free_attrs+0x98/0xd0 > [2.616827] sp : 800011db3970 > [2.620242] x29: 800011db3970 x28: 000f7b00 > [2.625695] x27: 1000 x26: 37b68410 > [2.631129] x25: 0001 x24: f7b0 > [2.636583] x23: x22: > [2.642017] x21: 800011b0d000 x20: 80001179b548 > [2.647461] x19: 37b68410 x18: 0010 > [2.652905] x17: 35d66a00 x16: deadbeef > [2.658348] x15: x14: 80001179b548 > [2.663792] x13: 800091db37b7 x12: 800011db37bf > [2.669236] x11: 8000117c7000 x10: 800011db3740 > [2.674680] x9 : ffd0 x8 : 80001071e980 > [2.680124] x7 : 0132 x6 : 80001197a6ab > [2.685568] x5 : x4 : > [2.691012] x3 : f7b0 x2 : fde0 > [2.696465] x1 : 0026c340 x0 : 0246c340 > [2.701899] Call trace: > [2.704452] xen_swiotlb_free_coherent+0x198/0x1d8 > [2.709367] dma_free_attrs+0x98/0xd0 > [2.713143] rpi_firmware_property_list+0x1e4/0x240 > [2.718146] rpi_firmware_property+0x6c/0xb0 > [2.722535] rpi_firmware_probe+0xf0/0x1e0 > [2.726760] platform_drv_probe+0x50/0xa0 > [2.730879] really_probe+0xd8/0x438 > [2.734567] driver_probe_device+0xdc/0x130 > [2.738870] __device_attach_driver+0x88/0x108 > [2.743434] bus_for_each_drv+0x78/0xc8 > [2.747386] __device_attach+0xd4/0x158 > [2.751337] device_initial_probe+0x10/0x18 > [2.755649] bus_probe_device+0x90/0x98 > [2.759590] deferred_probe_work_func+0x88/0xd8 > [2.764244] process_one_work+0x1f0/0x3c0 > [2.768369] worker_thread+0x138/0x570 > [2.772234] kthread+0x118/0x120 > [2.775571] ret_from_fork+0x10/0x18 > [2.779263] Code: d34cfc00 f2dfbfe2 d37ae400 8b020001 > (f8626800) > [2.785492] ---[ end trace 4c435212e349f45f ]--- > [2.793340] usb 1-1: New USB device found, idVendor=2109, > idProduct=3431, bcdDevice= 4.20 > [2.801038] usb 1-1: New USB device strings: Mfr=0, Product=1, > SerialNumber=0 > [2.808297] usb 1-1: Product: USB2.0 Hub > [2.813710] hub 1-1:1.0: USB hub found > [2.817117] hub 1-1:1.0: 4 ports detected > > This is bailing out right here: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > it.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.g > > it%2Ftree%2Fdrivers%2Ffirmware%2Fraspberrypi.c%3Fh%3Dv5.6.1%23n125 > & > > amp;data=02%7C01%7Cpeng.fan%40nxp.com%7Cab98b2db94484141a8ad0 > 8d7f18 > > 03372%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6372434052 > 335723 > > 54sdata=h1dyHkb%2FsifUqH3Z0m3uIIcqUhXVwhHS%2Ft%2FVvig%2Fo > u4%3D > reserved=0 > > FYIW (since I modified the source to actually print what was > returned right before it bails) we get:
Re: [PATCH] x86/svm: Use flush-by-asid when available
On Tue, May 05, 2020 at 07:25:39PM +0100, Andrew Cooper wrote:
> AMD Fam15h processors introduced the flush-by-asid feature, for more fine
> grain flushing purposes.
>
> Flushing everything including ASID 0 (i.e. Xen context) is an an unnecesserily
> large hammer, and never necessary in the context of guest TLBs needing
> invalidating.
>
> When available, use TLB_CTRL_FLUSH_ASID in preference to TLB_CTRL_FLUSH_ALL.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
I should also look into restricting the usage of FLUSH_HVM_ASID_CORE
and instead perform more fine grained per-vCPU flushes when possible,
since FLUSH_HVM_ASID_CORE resets the pCPU ASID generation forcing a
new ASID to be allocated for all vCPUs running on that pCPU.
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
>
> The APM currently describes tlb_control encoding 1 as "Flush entire
> TLB (Should be used only by legacy hypervisors.)". AMD have agreed that this
> is misleading and should say "legacy hardware" instead.
AFAICT using TLB_CTRL_FLUSH_ASID on hardware not supporting the
feature has not been found to be safe? Ie: TLB_CTRL_FLUSH_ALL is a
subset of TLB_CTRL_FLUSH_ASID from a bitmap PoV, so if those bits
where ignored on older hardware it should be safe to unconditionally
use it.
> This change does come with a minor observed perf improvement on Fam17h
> hardware, of ~0.6s over ~22s for my XTF pagewalk test. This test will spot
> TLB flushing issues, but isn't optimal for spotting the perf increase from
> better flushing. There were no observed differences for Fam15h, but this
> could simply mean that the measured code footprint was larger than the TLB on
> this CPU.
> ---
> xen/arch/x86/hvm/svm/asid.c | 9 ++---
> xen/include/asm-x86/hvm/svm/svm.h | 1 +
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
> index 9be90058c7..ab06dd3f3a 100644
> --- a/xen/arch/x86/hvm/svm/asid.c
> +++ b/xen/arch/x86/hvm/svm/asid.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> void svm_asid_init(const struct cpuinfo_x86 *c)
> {
> @@ -47,15 +48,17 @@ void svm_asid_handle_vmrun(void)
> if ( p_asid->asid == 0 )
> {
> vmcb_set_guest_asid(vmcb, 1);
> -/* TODO: investigate using TLB_CTRL_FLUSH_ASID here instead. */
> -vmcb->tlb_control = TLB_CTRL_FLUSH_ALL;
> +vmcb->tlb_control =
> +cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID :
> TLB_CTRL_FLUSH_ALL;
> return;
> }
>
> if ( vmcb_get_guest_asid(vmcb) != p_asid->asid )
> vmcb_set_guest_asid(vmcb, p_asid->asid);
>
> -vmcb->tlb_control = need_flush ? TLB_CTRL_FLUSH_ALL : TLB_CTRL_NO_FLUSH;
> +vmcb->tlb_control =
> +!need_flush ? TLB_CTRL_NO_FLUSH :
> +cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL;
Since this code structure is used in two places I would consider
locally introducing something like:
#define TLB_CTRL_FLUSH_CMD (cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID \
: TLB_CTRL_FLUSH_ALL)
To abstract it away.
Thanks, Roger.
Re: [RFC] UEFI Secure Boot on Xen Hosts
On Tue, 5 May 2020 at 23:58, Bobby Eshleman wrote: > > On Thu, Apr 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote: > > On Thu, 30 Apr 2020 at 13:15, Daniel Kiper wrote: > > > Anyway, the advantage of this new protocol is that it uses UEFI API to > > > load and execute PE kernel and its modules. This means that it will be > > > architecture independent. However, IIRC, if we want to add new modules > > > types to the Xen then we have to teach all bootloaders in the wild about > > > new GUIDs. Ard, am I correct? > > > > > > > Well, if you are passing multiple files that are not interchangeable, > > each bootloader will need to do something, right? It could be another > > GUID, or we could extend the initrd media device path to take > > discriminators. > > > > So today, we have > > > > VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68) > > > > which identifies /the/ initrd on Linux. As long as this keeps working > > as intended, I have no objections extending this to > > > > VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68)/File(...) > > > > etc, if we can agree that omitting the File() part means the unnamed > > initrd, and that L"initrd" is reserved as a file name. That way, you > > can choose any abstract file name you want, but please note that the > > loader still needs to provide some kind of mapping of how these > > abstract file names relate to actual files selected by the user. > > This seems reasonable to me and I can't think of any good reason right > now, if we go down this path, to not just extend the initrd media device > path (as opposed to creating one that is Xen-specific). It definitely > beats having a GUID per boot module since the number of modules changes > per Xen deployment, so there would need to be some range of GUIDs > representing modules specifically for Xen, and some rules as to how they > are mapped to real files. > > It does seem simpler to ask the loader for "dom0's kernel" or "dom1's > initrd" and to have the loader use these references to grab real files. > Yes. And note that using a single GUID + File component is easier on the implementation too: the protocol implementation has to be registered only once, and the single callback that exists will be invoked with different values for 'FilePath', corresponding with different values for File(). For example, in [0], this maps to the check at line 120, where we currently only consider the 'end-of-device-path' terminator type to be valid, but this could easily be extended to parse the contents of a subsequent file node and resolve it to grab some actual contents. [0] https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0 > > One thing to keep in mind, though, is that this protocol goes away > > after ExitBootServices(). > > > > Roger that. > > > Thanks, > > -Bobby
[xen-4.12-testing test] 150041: tolerable trouble: fail/pass/starved - PUSHED
flight 150041 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150041/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 149845 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen e43fc14ec58329813af876ed3b30899a04d65a08 baseline version: xen e6a2681148382e9227f54b70a5df8e895914c877 Last test of basis 149845 2020-04-28 03:00:06 Z8 days Testing same since 150041 2020-05-05 16:06:33 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Juergen Gross Julien Grall Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
