[xen-unstable test] 161917: regressions - FAIL
flight 161917 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/161917/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 161898 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 161898 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 92 xtf/test-pv32pae-xsa-286 fail in 161909 pass in 161917 test-arm64-arm64-libvirt-xsm 8 xen-boot fail pass in 161909 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail in 161909 never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail in 161909 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161898 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 161898 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 161898 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 161898 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 161898 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 161898 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 161898 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 161898 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161898 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 161898 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 161898 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 161898 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass version targeted for testing: xen d4fb5f166c2bfbaf9ba0de69da0d411288f437a9 baseline version: xen 982c89ed527bc5b0ffae5da9fd33f9d2d1528f06 Last test of basis 161898 2021-05-10 19:06:50 Z2 days Testing same since 161904 2021-05-11 10:00:22 Z1 days3 attempts People who touched revisions under test: Julien Grall Michal Orzel Volodymyr Babchuk jobs: build-amd64-xsm pass build-arm64-xsm
[xen-unstable-smoke test] 161923: tolerable all pass - PUSHED
flight 161923 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/161923/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 43d4cc7d36503bcc3aa2aa6ebea2b7912808f254 baseline version: xen 52b91dad6f43afb0c77325e6d54115c280958e57 Last test of basis 161921 2021-05-12 16:01:36 Z0 days Testing same since 161923 2021-05-12 21:01:32 Z0 days1 attempts People who touched revisions under test: Julien Grall 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 52b91dad6f..43d4cc7d36 43d4cc7d36503bcc3aa2aa6ebea2b7912808f254 -> smoke
[qemu-mainline test] 161915: regressions - FAIL
flight 161915 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161915/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-i386-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-libvirt-pair 25 guest-start/debian fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-libvirt-pair 25 guest-start/debian fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 152631 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never
Re: [PATCH RFCv2 10/15] xen/arm: mm: Allocate xen page tables in domheap rather than xenheap
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> xen_{un,}map_table() already uses the helper to map/unmap pages
> on-demand (note this is currently a NOP on arm64). So switching to
> domheap don't have any disavantage.
>
> But this as the benefit:
> - to keep the page tables unmapped if an arch decided to do so
> - reduce xenheap use on arm32 which can be pretty small
>
> Signed-off-by: Julien Grall
Thanks for the patch. It looks OK but let me ask a couple of questions
to clarify my doubts.
This change should have no impact to arm64, right?
For arm32, I wonder why we were using map_domain_page before in
xen_map_table: it wasn't necessary, was it? In fact, one could even say
that it was wrong?
> ---
> Changes in v2:
> - New patch
> ---
> xen/arch/arm/mm.c | 36 +---
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 19ecf73542ce..ae5a07ea956b 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -969,21 +969,6 @@ void *ioremap(paddr_t pa, size_t len)
> return ioremap_attr(pa, len, PAGE_HYPERVISOR_NOCACHE);
> }
>
> -static int create_xen_table(lpae_t *entry)
> -{
> -void *p;
> -lpae_t pte;
> -
> -p = alloc_xenheap_page();
> -if ( p == NULL )
> -return -ENOMEM;
> -clear_page(p);
> -pte = mfn_to_xen_entry(virt_to_mfn(p), MT_NORMAL);
> -pte.pt.table = 1;
> -write_pte(entry, pte);
> -return 0;
> -}
> -
> static lpae_t *xen_map_table(mfn_t mfn)
> {
> /*
> @@ -1024,6 +1009,27 @@ static void xen_unmap_table(const lpae_t *table)
> unmap_domain_page(table);
> }
>
> +static int create_xen_table(lpae_t *entry)
> +{
> +struct page_info *pg;
> +void *p;
> +lpae_t pte;
> +
> +pg = alloc_domheap_page(NULL, 0);
> +if ( pg == NULL )
> +return -ENOMEM;
> +
> +p = xen_map_table(page_to_mfn(pg));
> +clear_page(p);
> +xen_unmap_table(p);
> +
> +pte = mfn_to_xen_entry(page_to_mfn(pg), MT_NORMAL);
> +pte.pt.table = 1;
> +write_pte(entry, pte);
> +
> +return 0;
> +}
> +
> #define XEN_TABLE_MAP_FAILED 0
> #define XEN_TABLE_SUPER_PAGE 1
> #define XEN_TABLE_NORMAL_PAGE 2
> --
> 2.17.1
>
Re: [PATCH RFCv2 08/15] xen/arm32: mm: Check if the virtual address is shared before updating it
Hi Stefano, On 12/05/2021 23:00, Stefano Stabellini wrote: On Sun, 25 Apr 2021, Julien Grall wrote: From: Julien Grall Only the first 2GB of the virtual address space is shared between all the page-tables on Arm32. There is a long outstanding TODO in xen_pt_update() stating that the function is can only work with shared mapping. Nobody has ever called ^ remove the function with private mapping, however as we add more callers there is a risk to mess things up. Introduce a new define to mark the ened of the shared mappings and use ^end it in xen_pt_update() to verify if the address is correct. Note that on Arm64, all the mappings are shared. Some compiler may complain about an always true check, so the new define is not introduced for arm64 and the code is protected with an #ifdef. On arm64 we could maybe define SHARED_VIRT_END to an arbitrarely large value, such as: #define SHARED_VIRT_END (1UL<<48) or: #define SHARED_VIRT_END DIRECTMAP_VIRT_END ? I thought about it but I didn't want to define to a random value... I felt not define it was better. Signed-off-by: Julien Grall --- Changes in v2: - New patch --- xen/arch/arm/mm.c| 11 +-- xen/include/asm-arm/config.h | 4 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 8fac24d80086..5c17cafff847 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -1275,11 +1275,18 @@ static int xen_pt_update(unsigned long virt, * For arm32, page-tables are different on each CPUs. Yet, they share * some common mappings. It is assumed that only common mappings * will be modified with this function. - * - * XXX: Add a check. */ const mfn_t root = virt_to_mfn(THIS_CPU_PGTABLE); +#ifdef SHARED_VIRT_END +if ( virt > SHARED_VIRT_END || + (SHARED_VIRT_END - virt) < nr_mfns ) The following would be sufficient, right? if ( virt + nr_mfns > SHARED_VIRT_END ) This would not protect against an overflow. So I think it is best if we keep my version. Cheers, -- Julien Grall
Re: [PATCH RFCv2 07/15] xen/arm: mm: Re-implement early_fdt_map() using map_pages_to_xen()
Hi Stefano, On 12/05/2021 22:41, Stefano Stabellini wrote: On Sun, 25 Apr 2021, Julien Grall wrote: From: Julien Grall Now that map_pages_to_xen() has been extended to support 2MB mappings, we can replace the create_mappings() calls by map_pages_to_xen() calls. The mapping can also be marked read-only has Xen as no business to modify the host Device Tree. I think that's good. Just FYI there is some work at Xilinx to make changes to the device tree at runtime but we'll cross that bridge when we come to it. This particular mapping is only used during early boot. After the DT has been unflatten, this region is unmapped and the physical memory released. So if the DT needs to be modified at runtime, then you would most likely want to modify the unflatten version. Reviewed-by: Stefano Stabellini Thank you! Cheers, -- Julien Grall
Re: [PATCH RFCv2 02/15] xen/arm: lpae: Use the generic helpers to defined the Xen PT helpers
Hi Stefano, On 12/05/2021 22:30, Stefano Stabellini wrote: On Wed, 12 May 2021, Julien Grall wrote: +#define LPAE_SHIFT LPAE_SHIFT_GS(PAGE_SHIFT) +#define LPAE_ENTRIESLPAE_ENTRIES_GS(PAGE_SHIFT) +#define LPAE_ENTRY_MASK LPAE_ENTRY_MASK_GS(PAGE_SHIFT) +#define LEVEL_SHIFT(lvl)LEVEL_SHIFT_GS(PAGE_SHIFT, lvl) +#define LEVEL_ORDER(lvl)LEVEL_ORDER_GS(PAGE_SHIFT, lvl) +#define LEVEL_SIZE(lvl) LEVEL_SIZE_GS(PAGE_SHIFT, lvl) +#define LEVEL_MASK(lvl) (~(LEVEL_SIZE(lvl) - 1)) I would avoid adding these 4 macros. It would be OK if they were just used within this file but lpae.h is a header: they could end up be used anywhere in the xen/ code and they have a very generic name. My suggestion would be to skip them and just do: Those macros will be used in follow-up patches. They are pretty useful to avoid introduce static array with the different information for each level. Would prefix them with XEN_ be better? Maybe. The concern I have is that there are multiple page granularities (4kb, 16kb, etc) and multiple page sizes (4kb, 2mb, etc). If I just see LEVEL_ORDER it is not immediately obvious what granularity and what size we are talking about. I am a bit puzzled with your answer. AFAIU, you are happy with the existing macros (THIRD_*, SECOND_*) but not with the new macros. In reality, there is no difference because THIRD_* doesn't tell you the exact size but only "this is a level 3 mapping". So can you clarify what you are after? IOW is it reworking the current naming scheme? Cheers, -- Julien Grall
Re: [PATCH RFCv2 09/15] xen/arm32: mm: Re-implement setup_xenheap_mappings() using map_pages_to_xen()
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() call by map_pages_to_xen() call.
>
> Signed-off-by: Julien Grall
>
> ---
> Changes in v2:
> - New patch
>
> TODOs:
> - add support for contiguous mapping
> ---
> xen/arch/arm/mm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 5c17cafff847..19ecf73542ce 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -806,7 +806,12 @@ void mmu_init_secondary_cpu(void)
> void __init setup_xenheap_mappings(unsigned long base_mfn,
> unsigned long nr_mfns)
> {
> -create_mappings(xen_second, XENHEAP_VIRT_START, base_mfn, nr_mfns,
> MB(32));
> +int rc;
> +
> +rc = map_pages_to_xen(XENHEAP_VIRT_START, base_mfn, nr_mfns,
> + PAGE_HYPERVISOR_RW | _PAGE_BLOCK);
> +if ( rc )
> +panic("Unable to setup the xenheap mappings.\n");
>
> /* Record where the xenheap is, for translation routines. */
> xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
I get the following build error:
mm.c: In function ‘setup_xenheap_mappings’:
mm.c:811:47: error: incompatible type for argument 2 of ‘map_pages_to_xen’
rc = map_pages_to_xen(XENHEAP_VIRT_START, base_mfn, nr_mfns,
^~~~
In file included from mm.c:24:0:
/local/repos/xen-upstream/xen/include/xen/mm.h:89:5: note: expected ‘mfn_t {aka
struct }’ but argument is of type ‘long unsigned int’
int map_pages_to_xen(
^~~~
I think base_mfn needs to be converted to mfn_t
Re: [PATCH RFCv2 08/15] xen/arm32: mm: Check if the virtual address is shared before updating it
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Only the first 2GB of the virtual address space is shared between all
> the page-tables on Arm32.
>
> There is a long outstanding TODO in xen_pt_update() stating that the
> function is can only work with shared mapping. Nobody has ever called
^ remove
> the function with private mapping, however as we add more callers
> there is a risk to mess things up.
>
> Introduce a new define to mark the ened of the shared mappings and use
^end
> it in xen_pt_update() to verify if the address is correct.
>
> Note that on Arm64, all the mappings are shared. Some compiler may
> complain about an always true check, so the new define is not introduced
> for arm64 and the code is protected with an #ifdef.
On arm64 we could maybe define SHARED_VIRT_END to an arbitrarely large
value, such as:
#define SHARED_VIRT_END (1UL<<48)
or:
#define SHARED_VIRT_END DIRECTMAP_VIRT_END
?
> Signed-off-by: Julien Grall
>
> ---
> Changes in v2:
> - New patch
> ---
> xen/arch/arm/mm.c| 11 +--
> xen/include/asm-arm/config.h | 4
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 8fac24d80086..5c17cafff847 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1275,11 +1275,18 @@ static int xen_pt_update(unsigned long virt,
> * For arm32, page-tables are different on each CPUs. Yet, they share
> * some common mappings. It is assumed that only common mappings
> * will be modified with this function.
> - *
> - * XXX: Add a check.
> */
> const mfn_t root = virt_to_mfn(THIS_CPU_PGTABLE);
>
> +#ifdef SHARED_VIRT_END
> +if ( virt > SHARED_VIRT_END ||
> + (SHARED_VIRT_END - virt) < nr_mfns )
The following would be sufficient, right?
if ( virt + nr_mfns > SHARED_VIRT_END )
> +{
> +mm_printk("Trying to map outside of the shared area.\n");
> +return -EINVAL;
> +}
> +#endif
> +
> /*
> * The hardware was configured to forbid mapping both writeable and
> * executable.
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index c7b77912013e..85d4a510ce8a 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -137,6 +137,10 @@
>
> #define XENHEAP_VIRT_START _AT(vaddr_t,0x4000)
> #define XENHEAP_VIRT_END _AT(vaddr_t,0x7fff)
> +
> +/* The first 2GB is always shared between all the page-tables. */
> +#define SHARED_VIRT_END_AT(vaddr_t, 0x7fff)
> +
> #define DOMHEAP_VIRT_START _AT(vaddr_t,0x8000)
> #define DOMHEAP_VIRT_END _AT(vaddr_t,0x)
>
> --
> 2.17.1
>
Re: [PATCH RFCv2 07/15] xen/arm: mm: Re-implement early_fdt_map() using map_pages_to_xen()
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() calls by map_pages_to_xen() calls.
>
> The mapping can also be marked read-only has Xen as no business to
> modify the host Device Tree.
I think that's good. Just FYI there is some work at Xilinx to make
changes to the device tree at runtime but we'll cross that bridge when
we come to it.
Reviewed-by: Stefano Stabellini
> Signed-off-by: Julien Grall
> Signed-off-by: Julien Grall
>
> ---
> Changes in v2:
> - Add my AWS signed-off-by
> - Fix typo in the commit message
> ---
> xen/arch/arm/mm.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 2cbfbe25240e..8fac24d80086 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -558,6 +558,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
> paddr_t offset;
> void *fdt_virt;
> uint32_t size;
> +int rc;
>
> /*
> * Check whether the physical FDT address is set and meets the minimum
> @@ -573,8 +574,12 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
> /* The FDT is mapped using 2MB superpage */
> BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
>
> -create_mappings(xen_second, BOOT_FDT_VIRT_START,
> paddr_to_pfn(base_paddr),
> -SZ_2M >> PAGE_SHIFT, SZ_2M);
> +rc = map_pages_to_xen(BOOT_FDT_VIRT_START, maddr_to_mfn(base_paddr),
> + SZ_2M >> PAGE_SHIFT,
> + PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> +if ( rc )
> +panic("Unable to map the device-tree.\n");
> +
>
> offset = fdt_paddr % SECOND_SIZE;
> fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
> @@ -588,9 +593,12 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
>
> if ( (offset + size) > SZ_2M )
> {
> -create_mappings(xen_second, BOOT_FDT_VIRT_START + SZ_2M,
> -paddr_to_pfn(base_paddr + SZ_2M),
> -SZ_2M >> PAGE_SHIFT, SZ_2M);
> +rc = map_pages_to_xen(BOOT_FDT_VIRT_START + SZ_2M,
> + maddr_to_mfn(base_paddr + SZ_2M),
> + SZ_2M >> PAGE_SHIFT,
> + PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> +if ( rc )
> +panic("Unable to map the device-tree\n");
> }
>
> return fdt_virt;
> --
> 2.17.1
>
Re: [PATCH RFCv2 02/15] xen/arm: lpae: Use the generic helpers to defined the Xen PT helpers
On Wed, 12 May 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 11/05/2021 23:26, Stefano Stabellini wrote:
> > On Sun, 25 Apr 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Currently, Xen PT helpers are only working with 4KB page granularity
> > > and open-code the generic helpers. To allow more flexibility, we can
> > > re-use the generic helpers and pass Xen's page granularity
> > > (PAGE_SHIFT).
> > >
> > > As Xen PT helpers are used in both C and assembly, we need to move
> > > the generic helpers definition outside of the !__ASSEMBLY__ section.
> > >
> > > Note the aliases for each level are still kept for the time being so we
> > > can avoid a massive patch to change all the callers.
> > >
> > > Signed-off-by: Julien Grall
> >
> > The patch is OK as is. I have a couple of suggestions for improvement
> > below. If you feel like making them, good, otherwise I am also OK if you
> > don't want to change anything.
> >
> >
> > > ---
> > > Changes in v2:
> > > - New patch
> > > ---
> > > xen/include/asm-arm/lpae.h | 71 +-
> > > 1 file changed, 40 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> > > index 4fb9a40a4ca9..310f5225e056 100644
> > > --- a/xen/include/asm-arm/lpae.h
> > > +++ b/xen/include/asm-arm/lpae.h
> > > @@ -159,6 +159,17 @@ static inline bool lpae_is_superpage(lpae_t pte,
> > > unsigned int level)
> > > #define lpae_get_mfn(pte)(_mfn((pte).walk.base))
> > > #define lpae_set_mfn(pte, mfn) ((pte).walk.base = mfn_x(mfn))
> > > +/* Generate an array @var containing the offset for each level from
> > > @addr */
> > > +#define DECLARE_OFFSETS(var, addr) \
> > > +const unsigned int var[4] = { \
> > > +zeroeth_table_offset(addr), \
> > > +first_table_offset(addr), \
> > > +second_table_offset(addr), \
> > > +third_table_offset(addr)\
> > > +}
> > > +
> > > +#endif /* __ASSEMBLY__ */
> > > +
> > > /*
> > >* AArch64 supports pages with different sizes (4K, 16K, and 64K).
> > >* Provide a set of generic helpers that will compute various
> > > @@ -190,17 +201,6 @@ static inline bool lpae_is_superpage(lpae_t pte,
> > > unsigned int level)
> > > #define LPAE_TABLE_INDEX_GS(gs, lvl, addr) \
> > > (((addr) >> LEVEL_SHIFT_GS(gs, lvl)) & LPAE_ENTRY_MASK_GS(gs))
> > > -/* Generate an array @var containing the offset for each level from
> > > @addr */
> > > -#define DECLARE_OFFSETS(var, addr) \
> > > -const unsigned int var[4] = { \
> > > -zeroeth_table_offset(addr), \
> > > -first_table_offset(addr), \
> > > -second_table_offset(addr), \
> > > -third_table_offset(addr)\
> > > -}
> > > -
> > > -#endif /* __ASSEMBLY__ */
> > > -
> > > /*
> > >* These numbers add up to a 48-bit input address space.
> > >*
> > > @@ -211,26 +211,35 @@ static inline bool lpae_is_superpage(lpae_t pte,
> > > unsigned int level)
> > >* therefore 39-bits are sufficient.
> > >*/
> > > -#define LPAE_SHIFT 9
> > > -#define LPAE_ENTRIES(_AC(1,U) << LPAE_SHIFT)
> > > -#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
> > > -
> > > -#define THIRD_SHIFT(PAGE_SHIFT)
> > > -#define THIRD_ORDER(THIRD_SHIFT - PAGE_SHIFT)
> > > -#define THIRD_SIZE (_AT(paddr_t, 1) << THIRD_SHIFT)
> > > -#define THIRD_MASK (~(THIRD_SIZE - 1))
> > > -#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
> > > -#define SECOND_ORDER (SECOND_SHIFT - PAGE_SHIFT)
> > > -#define SECOND_SIZE(_AT(paddr_t, 1) << SECOND_SHIFT)
> > > -#define SECOND_MASK(~(SECOND_SIZE - 1))
> > > -#define FIRST_SHIFT(SECOND_SHIFT + LPAE_SHIFT)
> > > -#define FIRST_ORDER(FIRST_SHIFT - PAGE_SHIFT)
> > > -#define FIRST_SIZE (_AT(paddr_t, 1) << FIRST_SHIFT)
> > > -#define FIRST_MASK (~(FIRST_SIZE - 1))
> > > -#define ZEROETH_SHIFT (FIRST_SHIFT + LPAE_SHIFT)
> > > -#define ZEROETH_ORDER (ZEROETH_SHIFT - PAGE_SHIFT)
> > > -#define ZEROETH_SIZE (_AT(paddr_t, 1) << ZEROETH_SHIFT)
> > > -#define ZEROETH_MASK (~(ZEROETH_SIZE - 1))
> >
> > Should we add a one-line in-code comment saying that the definitions
> > below are for 4KB pages? It is not immediately obvious any longer.
>
> Because they are not meant to be for 4KB pages. They are meant to be for Xen
> page size.
>
> Today, it is always 4KB but I would like the Xen code to not rely on that.
>
> I can clarify it in an in-code comment.
That would help I think
> > > +#define LPAE_SHIFT LPAE_SHIFT_GS(PAGE_SHIFT)
> > > +#define LPAE_ENTRIESLPAE_ENTRIES_GS(PAGE_SHIFT)
> > > +#define LPAE_ENTRY_MASK LPAE_ENTRY_MASK_GS(PAGE_SHIFT)
> > >
> > > +#define LEVEL_SHIFT(lvl)LEVEL_SHIFT_GS(PAGE_SHIFT, lvl)
> > > +#define LEVEL_ORDER(lvl)LEVEL_ORDER_GS(PAGE_SHIFT, lvl)
> > > +#define
Re: [PATCH] xen/arm: gic-v3: Add missing breaks gicv3_read_apr()
On Wed, 12 May 2021, Julien Grall wrote:
> From: Julien Grall
>
> Commit 78e67c99eb3f "arm/gic: Get rid of READ/WRITE_SYSREG32"
> mistakenly converted all the cases in gicv3_read_apr() to fall-through.
>
> Rather than re-instating a return per case, add the missing break and
> keep a single return at the end of the fucntion.
>
> Fixes: 78e67c99eb3f ("arm/gic: Get rid of READ/WRITE_SYSREG32")
> Signed-off-by: Julien Grall
reviewed and committed
> ---
> xen/arch/arm/gic-v3.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index b86f04058947..9a3a175ad7d2 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1167,12 +1167,15 @@ static unsigned int gicv3_read_apr(int apr_reg)
> case 0:
> ASSERT(gicv3.nr_priorities > 4 && gicv3.nr_priorities < 8);
> apr = READ_SYSREG(ICH_AP1R0_EL2);
> +break;
> case 1:
> ASSERT(gicv3.nr_priorities > 5 && gicv3.nr_priorities < 8);
> apr = READ_SYSREG(ICH_AP1R1_EL2);
> +break;
> case 2:
> ASSERT(gicv3.nr_priorities > 6 && gicv3.nr_priorities < 8);
> apr = READ_SYSREG(ICH_AP1R2_EL2);
> +break;
> default:
> BUG();
> }
> --
> 2.17.1
>
[PATCH v2 1/3] xen/arm: move xen_swiotlb_detect to arm/swiotlb-xen.h
From: Stefano Stabellini
Move xen_swiotlb_detect to a static inline function to make it available
to !CONFIG_XEN builds.
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- patch split
---
arch/arm/xen/mm.c | 12
include/xen/arm/swiotlb-xen.h | 15 ++-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index f8f07469d259..223b1151fd7d 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -135,18 +135,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
return;
}
-int xen_swiotlb_detect(void)
-{
- if (!xen_domain())
- return 0;
- if (xen_feature(XENFEAT_direct_mapped))
- return 1;
- /* legacy case */
- if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
- return 1;
- return 0;
-}
-
static int __init xen_mm_init(void)
{
struct gnttab_cache_flush cflush;
diff --git a/include/xen/arm/swiotlb-xen.h b/include/xen/arm/swiotlb-xen.h
index 2994fe6031a0..6ab58afc 100644
--- a/include/xen/arm/swiotlb-xen.h
+++ b/include/xen/arm/swiotlb-xen.h
@@ -2,6 +2,19 @@
#ifndef _ASM_ARM_SWIOTLB_XEN_H
#define _ASM_ARM_SWIOTLB_XEN_H
-extern int xen_swiotlb_detect(void);
+#include
+#include
+
+static inline int xen_swiotlb_detect(void)
+{
+ if (!xen_domain())
+ return 0;
+ if (xen_feature(XENFEAT_direct_mapped))
+ return 1;
+ /* legacy case */
+ if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
+ return 1;
+ return 0;
+}
#endif /* _ASM_ARM_SWIOTLB_XEN_H */
--
2.17.1
[PATCH v2 3/3] xen/swiotlb: check if the swiotlb has already been initialized
From: Stefano Stabellini
xen_swiotlb_init calls swiotlb_late_init_with_tbl, which fails with
-ENOMEM if the swiotlb has already been initialized.
Add an explicit check io_tlb_default_mem != NULL at the beginning of
xen_swiotlb_init. If the swiotlb is already initialized print a warning
and return -EEXIST.
On x86, the error propagates.
On ARM, we don't actually need a special swiotlb buffer (yet), any
buffer would do. So ignore the error and continue.
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
---
Changes in v2:
- use pr_warn
- add reviewed-by
---
arch/arm/xen/mm.c | 8 +++-
drivers/xen/swiotlb-xen.c | 5 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 223b1151fd7d..a7e54a087b80 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -138,9 +138,15 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
static int __init xen_mm_init(void)
{
struct gnttab_cache_flush cflush;
+ int rc;
+
if (!xen_swiotlb_detect())
return 0;
- xen_swiotlb_init();
+
+ rc = xen_swiotlb_init();
+ /* we can work with the default swiotlb */
+ if (rc < 0 && rc != -EEXIST)
+ return rc;
cflush.op = 0;
cflush.a.dev_bus_addr = 0;
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 4c89afc0df62..24d11861ac7d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,6 +164,11 @@ int __ref xen_swiotlb_init(void)
int rc = -ENOMEM;
char *start;
+ if (io_tlb_default_mem != NULL) {
+ pr_warn("swiotlb buffer already initialized\n");
+ return -EEXIST;
+ }
+
retry:
m_ret = XEN_SWIOTLB_ENOMEM;
order = get_order(bytes);
--
2.17.1
[PATCH v2 2/3] arm64: do not set SWIOTLB_NO_FORCE when swiotlb is required
From: Christoph Hellwig
Although SWIOTLB_NO_FORCE is meant to allow later calls to swiotlb_init,
today dma_direct_map_page returns error if SWIOTLB_NO_FORCE.
For now, without a larger overhaul of SWIOTLB_NO_FORCE, the best we can
do is to avoid setting SWIOTLB_NO_FORCE in mem_init when we know that it
is going to be required later (e.g. Xen requires it).
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: catalin.mari...@arm.com
CC: w...@kernel.org
CC: linux-arm-ker...@lists.infradead.org
Fixes: 2726bf3ff252 ("swiotlb: Make SWIOTLB_NO_FORCE perform no allocation")
Signed-off-by: Christoph Hellwig
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- patch split
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 16a2b2b1c54d..e55409caaee3 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
/*
* We need to be able to catch inadvertent references to memstart_addr
@@ -482,7 +483,7 @@ void __init mem_init(void)
if (swiotlb_force == SWIOTLB_FORCE ||
max_pfn > PFN_DOWN(arm64_dma_phys_limit))
swiotlb_init(1);
- else
+ else if (!xen_swiotlb_detect())
swiotlb_force = SWIOTLB_NO_FORCE;
set_max_mapnr(max_pfn - PHYS_PFN_OFFSET);
--
2.17.1
[PATCH v2 0/3] swiotlb-xen init fixes
Hi all, This short patch series comes with a preparation patch and 2 unrelated fixes to swiotlb-xen initialization. Christoph Hellwig (1): arm64: do not set SWIOTLB_NO_FORCE when swiotlb is required Stefano Stabellini (2): xen/arm: move xen_swiotlb_detect to arm/swiotlb-xen.h xen/swiotlb: check if the swiotlb has already been initialized arch/arm/xen/mm.c | 20 +++- arch/arm64/mm/init.c | 3 ++- drivers/xen/swiotlb-xen.c | 5 + include/xen/arm/swiotlb-xen.h | 15 ++- 4 files changed, 28 insertions(+), 15 deletions(-)
Re: [PATCH 2/2] xen/swiotlb: check if the swiotlb has already been initialized
On Tue, 11 May 2021, Boris Ostrovsky wrote:
> On 5/11/21 1:41 PM, Stefano Stabellini wrote:
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -164,6 +164,11 @@ int __ref xen_swiotlb_init(void)
> > int rc = -ENOMEM;
> > char *start;
> >
> > + if (io_tlb_default_mem != NULL) {
> > + printk(KERN_WARNING "Xen-SWIOTLB: swiotlb buffer already
> > initialized\n");
>
>
> pr_warn().
>
>
> Reviewed-by: Boris Ostrovsky
Thank you! I'll send a v2 shortly with the change to pr_warn and your
reviewed-by.
Re: [PATCH 1/2] xen/arm64: do not set SWIOTLB_NO_FORCE when swiotlb is required
On Wed, 12 May 2021, Christoph Hellwig wrote:
> > -int xen_swiotlb_detect(void)
> > -{
> > - if (!xen_domain())
> > - return 0;
> > - if (xen_feature(XENFEAT_direct_mapped))
> > - return 1;
> > - /* legacy case */
> > - if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
> > - return 1;
> > - return 0;
> > -}
>
> I think this move should be a separate prep patch.
Sure, I can do that
[xen-unstable-smoke test] 161921: tolerable all pass - PUSHED
flight 161921 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/161921/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 52b91dad6f43afb0c77325e6d54115c280958e57 baseline version: xen d4fb5f166c2bfbaf9ba0de69da0d411288f437a9 Last test of basis 161897 2021-05-10 19:02:36 Z2 days Testing same since 161921 2021-05-12 16:01:36 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Olaf Hering 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 d4fb5f166c..52b91dad6f 52b91dad6f43afb0c77325e6d54115c280958e57 -> smoke
Re: [PATCH v3 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
On 12/05/2021 18:59, Julien Grall wrote:
> Hi,
>
> On 11/05/2021 07:37, Michal Orzel wrote:
>> On 05.05.2021 10:00, Jan Beulich wrote:
>>> On 05.05.2021 09:43, Michal Orzel wrote:
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
/* Return address and mode */
__DECL_REG(pc64, pc32); /* ELR_EL2 */
- uint32_t cpsr; /* SPSR_EL2 */
+ uint64_t cpsr; /* SPSR_EL2 */
union {
- uint32_t spsr_el1; /* AArch64 */
+ uint64_t spsr_el1; /* AArch64 */
uint32_t spsr_svc; /* AArch32 */
};
>>>
>>> This change affects, besides domctl, also default_initialise_vcpu(),
>>> which Arm's arch_initialise_vcpu() calls. I realize do_arm_vcpu_op()
>>> only allows two unrelated VCPUOP_* to pass, but then I don't
>>> understand why arch_initialise_vcpu() doesn't simply return e.g.
>>> -EOPNOTSUPP. Hence I suspect I'm missing something.
>
> I think it is just an overlooked when reviewing the following commit:
>
> commit 192df6f9122ddebc21d0a632c10da3453aeee1c2
> Author: Roger Pau Monné
> Date: Tue Dec 15 14:12:32 2015 +0100
>
> x86: allow HVM guests to use hypercalls to bring up vCPUs
>
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls
> from HVM
> guests.
>
> This patch introduces a new structure (vcpu_hvm_context) that
> should be used
> in conjuction with the VCPUOP_initialise hypercall in order to
> initialize
> vCPUs for HVM guests.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> Acked-by: Ian Campbell
>
> On Arm, the structure vcpu_guest_context is not exposed outside of Xen
> and the tools. Interestingly vcpu_guest_core_regs is but it should
> only be used within vcpu_guest_context.
>
> So as this is not used by stable ABI, it is fine to break it.
>
>>>
>> I agree that do_arm_vcpu_op only allows two VCPUOP* to pass and
>> arch_initialise_vcpu being called in case of VCPUOP_initialise
>> has no sense as VCPUOP_initialise is not supported on arm.
>> It makes sense that it should return -EOPNOTSUPP.
>> However do_arm_vcpu_op will not accept VCPUOP_initialise and will return
>> -EINVAL. So arch_initialise_vcpu for arm will not be called.
>> Do you think that changing this behaviour so that
>> arch_initialise_vcpu returns
>> -EOPNOTSUPP should be part of this patch?
>
> I think this change is unrelated. So it should be handled in a
> follow-up patch.
>
> If you are taking care of this, would you mind to also look to move
> struct vcpu_guest_core_regs within the #if defined(__XEN__) ||
> defined(__XEN_TOOLS__)?
+1. Fairly sure this is the conclusion of a discussion a year or so
back where I noted the same peculiarity, and tried to untangle the mess
which is the common vs arch specific code. (which is still outstanding,
and I don't immediately recall why.)
~Andrew
Re: [PATCH v3 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Hi,
On 11/05/2021 07:37, Michal Orzel wrote:
On 05.05.2021 10:00, Jan Beulich wrote:
On 05.05.2021 09:43, Michal Orzel wrote:
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
/* Return address and mode */
__DECL_REG(pc64, pc32); /* ELR_EL2 */
-uint32_t cpsr; /* SPSR_EL2 */
+uint64_t cpsr; /* SPSR_EL2 */
union {
-uint32_t spsr_el1; /* AArch64 */
+uint64_t spsr_el1; /* AArch64 */
uint32_t spsr_svc; /* AArch32 */
};
This change affects, besides domctl, also default_initialise_vcpu(),
which Arm's arch_initialise_vcpu() calls. I realize do_arm_vcpu_op()
only allows two unrelated VCPUOP_* to pass, but then I don't
understand why arch_initialise_vcpu() doesn't simply return e.g.
-EOPNOTSUPP. Hence I suspect I'm missing something.
I think it is just an overlooked when reviewing the following commit:
commit 192df6f9122ddebc21d0a632c10da3453aeee1c2
Author: Roger Pau Monné
Date: Tue Dec 15 14:12:32 2015 +0100
x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
guests.
This patch introduces a new structure (vcpu_hvm_context) that
should be used
in conjuction with the VCPUOP_initialise hypercall in order to
initialize
vCPUs for HVM guests.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Acked-by: Ian Campbell
On Arm, the structure vcpu_guest_context is not exposed outside of Xen
and the tools. Interestingly vcpu_guest_core_regs is but it should only
be used within vcpu_guest_context.
So as this is not used by stable ABI, it is fine to break it.
I agree that do_arm_vcpu_op only allows two VCPUOP* to pass and
arch_initialise_vcpu being called in case of VCPUOP_initialise
has no sense as VCPUOP_initialise is not supported on arm.
It makes sense that it should return -EOPNOTSUPP.
However do_arm_vcpu_op will not accept VCPUOP_initialise and will return
-EINVAL. So arch_initialise_vcpu for arm will not be called.
Do you think that changing this behaviour so that arch_initialise_vcpu returns
-EOPNOTSUPP should be part of this patch?
I think this change is unrelated. So it should be handled in a follow-up
patch.
If you are taking care of this, would you mind to also look to move
struct vcpu_guest_core_regs within the #if defined(__XEN__) ||
defined(__XEN_TOOLS__)?
I will attempt to do a proper review of this patch by the end of the week.
Cheers,
--
Julien Grall
[PATCH] xen/arm: gic-v3: Add missing breaks gicv3_read_apr()
From: Julien Grall
Commit 78e67c99eb3f "arm/gic: Get rid of READ/WRITE_SYSREG32"
mistakenly converted all the cases in gicv3_read_apr() to fall-through.
Rather than re-instating a return per case, add the missing break and
keep a single return at the end of the fucntion.
Fixes: 78e67c99eb3f ("arm/gic: Get rid of READ/WRITE_SYSREG32")
Signed-off-by: Julien Grall
---
xen/arch/arm/gic-v3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b86f04058947..9a3a175ad7d2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1167,12 +1167,15 @@ static unsigned int gicv3_read_apr(int apr_reg)
case 0:
ASSERT(gicv3.nr_priorities > 4 && gicv3.nr_priorities < 8);
apr = READ_SYSREG(ICH_AP1R0_EL2);
+break;
case 1:
ASSERT(gicv3.nr_priorities > 5 && gicv3.nr_priorities < 8);
apr = READ_SYSREG(ICH_AP1R1_EL2);
+break;
case 2:
ASSERT(gicv3.nr_priorities > 6 && gicv3.nr_priorities < 8);
apr = READ_SYSREG(ICH_AP1R2_EL2);
+break;
default:
BUG();
}
--
2.17.1
[linux-linus test] 161911: regressions - FAIL
flight 161911 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/161911/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152332 test-arm64-arm64-examine 8 reboot fail REGR. vs. 152332 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 152332 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 152332 test-amd64-amd64-libvirt-vhd 13 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 152332 test-amd64-amd64-xl-qcow213 guest-start fail REGR. vs. 152332 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 152332 test-armhf-armhf-xl-vhd 13 guest-start fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15
[PATCH] include/public: add RING_RESPONSE_PROD_OVERFLOW macro
Add a new RING_RESPONSE_PROD_OVERFLOW() macro for being able to
detect an ill-behaved backend tampering with the response producer
index.
Signed-off-by: Juergen Gross
---
xen/include/public/io/ring.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 0b08b2697e..c486c457e0 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -259,6 +259,10 @@ typedef struct __name##_back_ring __name##_back_ring_t
#define RING_REQUEST_PROD_OVERFLOW(_r, _prod) \
(((_prod) - (_r)->rsp_prod_pvt) > RING_SIZE(_r))
+/* Ill-behaved backend determination: Can there be this many responses? */
+#define RING_RESPONSE_PROD_OVERFLOW(_r, _prod) \
+(((_prod) - (_r)->rsp_cons) > RING_SIZE(_r))
+
#define RING_PUSH_REQUESTS(_r) do { \
xen_wmb(); /* back sees requests /before/ updated producer index */ \
(_r)->sring->req_prod = (_r)->req_prod_pvt; \
--
2.26.2
Re: [PATCH v2] tools: remove unused sysconfig variable XENSTORED_ROOTDIR
On 12/05/2021 16:07, Olaf Hering wrote: > Am Wed, 12 May 2021 15:52:16 +0100 > schrieb Andrew Cooper : > >> Olaf: View on the above? > I'm fine with the additional CHANGELOG.md change. > I thought the suggested addition is obvious. Thanks, but as I'm folding it into your patch, I shouldn't do it unilaterally without someone else saying ok. As it happens, Wei offered his A-by on IRC for the change, so I'll go ahead as suggested. ~Andrew
Re: [PATCH 2/3] xen: Export dbgp functions when CONFIG_XEN_DOM0 is enabled
On 5/12/21 10:58 AM, Connor Davis wrote: > On May 12, 21, Boris Ostrovsky wrote: >> Unrelated to your patch but since you are fixing things around that file --- >> should we return -EPERM in xen_dbgp_op() when !xen_initial_domain()? > Yeah looks like it. That would make patch 3 simpler too. > Do you want me to add a patch that fixes that up? Yes, please. -boris
Re: [PATCH v2] tools: remove unused sysconfig variable XENSTORED_ROOTDIR
Am Wed, 12 May 2021 15:52:16 +0100 schrieb Andrew Cooper : > Olaf: View on the above? I'm fine with the additional CHANGELOG.md change. I thought the suggested addition is obvious. Olaf pgp5D6yxfm7Mk.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2 00/17] live update and gnttab patches
On Wed, 2021-05-12 at 13:51 +0100, Andrew Cooper wrote: > On 12/05/2021 11:10, Edwin Torok wrote: > > On Tue, 2021-05-11 at 21:05 +0100, Andrew Cooper wrote: > > > > > diff --git a/tools/ocaml/xenstored/disk.ml > > b/tools/ocaml/xenstored/disk.ml > > index 59794324e1..b7678af87f 100644 > > --- a/tools/ocaml/xenstored/disk.ml > > +++ b/tools/ocaml/xenstored/disk.ml > > @@ -176,7 +176,7 @@ let write store = > > output_byte ch i > > > > let w32 ch v = > > - assert (v >= 0 && v <= 0x_); > > + assert (v >= 0 && Int64.of_int v <= 0x_L); > > In the case that v is 32 bits wide, it will underflow and fail the v > >= > 0 check, before the upcast to Int64. I'll have to review the callers of this, I think my intention was to forbid dumping negative values because it is ambigous what it means. In case you are running on 64-bit that is most likely a bug because I think most 32-bit values were defined as unsigned in the migration spec or in the original xen public headers (I'll have to double check). However in case of a 32-bit system we can have negative values where an otherwise unsigned 32-bit quantity in xen is represented as an ocaml int, or even silently truncated (if the xen value actually uses all 32- bits, because OCaml ints are only 31-bits on 32-bit systems, one would have to use the int32 type to get true 32-bit quantities in ocaml but that comes with additional boxing and a more complicated syntax, so in most places in Xen I see the difference just being ignored). Perhaps this should forbid negative values only on 64-bit systems (where that would be a bug), and allow it on 32-bit systems (where a negative value might be legitimate or a bug, we can't tell). Checking Sys.word_size should tell us what system we are on. Best regards, --Edwin
Re: [PATCH 2/3] xen: Export dbgp functions when CONFIG_XEN_DOM0 is enabled
On May 12, 21, Juergen Gross wrote: > On 12.05.21 02:18, Connor Davis wrote: > > Export xen_dbgp_reset_prep and xen_dbgp_external_startup > > when CONFIG_XEN_DOM0 is defined. This allows use of these symbols > > even if CONFIG_EARLY_PRINK_DBGP is defined. > > > > Signed-off-by: Connor Davis > > Acked-by: Juergen Gross Thank you. - Connor
Re: [PATCH 3/3] usb: xhci: Notify xen when DbC is unsafe to use
On May 12, 21, Greg Kroah-Hartman wrote: > On Tue, May 11, 2021 at 06:18:21PM -0600, Connor Davis wrote: > > When running as a dom0 guest on Xen, check if the USB3 debug > > capability is enabled before xHCI reset, suspend, and resume. If it > > is, call xen_dbgp_reset_prep() to notify Xen that it is unsafe to touch > > MMIO registers until the next xen_dbgp_external_startup(). > > > > This notification allows Xen to avoid undefined behavior resulting > > from MMIO access when the host controller's CNR bit is set or when > > the device transitions to D3hot. > > > > Signed-off-by: Connor Davis > > --- > > drivers/usb/host/xhci-dbgcap.h | 6 > > drivers/usb/host/xhci.c| 57 ++ > > drivers/usb/host/xhci.h| 1 + > > 3 files changed, 64 insertions(+) > > > > diff --git a/drivers/usb/host/xhci-dbgcap.h b/drivers/usb/host/xhci-dbgcap.h > > index c70b78d504eb..24784b82a840 100644 > > --- a/drivers/usb/host/xhci-dbgcap.h > > +++ b/drivers/usb/host/xhci-dbgcap.h > > @@ -227,4 +227,10 @@ static inline int xhci_dbc_resume(struct xhci_hcd > > *xhci) > > return 0; > > } > > #endif /* CONFIG_USB_XHCI_DBGCAP */ > > + > > +#ifdef CONFIG_XEN_DOM0 > > +int xen_dbgp_reset_prep(struct usb_hcd *hcd); > > +int xen_dbgp_external_startup(struct usb_hcd *hcd); > > +#endif /* CONFIG_XEN_DOM0 */ > > + > > #endif /* __LINUX_XHCI_DBGCAP_H */ > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > > index ca9385d22f68..afe44169183f 100644 > > --- a/drivers/usb/host/xhci.c > > +++ b/drivers/usb/host/xhci.c > > @@ -37,6 +37,57 @@ static unsigned long long quirks; > > module_param(quirks, ullong, S_IRUGO); > > MODULE_PARM_DESC(quirks, "Bit flags for quirks to be enabled as default"); > > > > +#ifdef CONFIG_XEN_DOM0 > > +#include > > > > Can't this #ifdef stuff go into a .h file? > Yep, will clean that up in v2. > thanks, > > greg k-h Thanks, Connor
Re: [PATCH 2/3] xen: Export dbgp functions when CONFIG_XEN_DOM0 is enabled
On May 12, 21, Boris Ostrovsky wrote: > > On 5/11/21 8:18 PM, Connor Davis wrote: > > Export xen_dbgp_reset_prep and xen_dbgp_external_startup > > when CONFIG_XEN_DOM0 is defined. This allows use of these symbols > > even if CONFIG_EARLY_PRINK_DBGP is defined. > > > > Signed-off-by: Connor Davis > > --- > > drivers/xen/dbgp.c | 2 +- > > > Unrelated to your patch but since you are fixing things around that file --- > should we return -EPERM in xen_dbgp_op() when !xen_initial_domain()? Yeah looks like it. That would make patch 3 simpler too. Do you want me to add a patch that fixes that up? > > -boris > Thanks, Connor
Re: [PATCH v2] tools: remove unused sysconfig variable XENSTORED_ROOTDIR
On 06/05/2021 17:49, Andrew Cooper wrote: > On 06/05/2021 16:16, Olaf Hering wrote: >> The sysconfig variable XENSTORED_ROOTDIR is not used anymore. >> It used to point to a directory with tdb files, which is now a tmpfs. >> >> In case the database is not in tmpfs, like on sysv and BSD systems, >> xenstored will truncate existing database files during start. >> >> Fixes commit 2ef6ace428dec4795b8b0a67fff6949e817013de >> >> Signed-off-by: Olaf Hering > Acked-by Andrew Cooper , although as we're > trying to keep on top of the changelog this time around, we probably > want the following hunk: > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 0106fccec1..6896d70757 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -6,6 +6,10 @@ The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > > ## [unstable > UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=staging) > - TBD > > +### Removed > + - XENSTORED_ROOTDIR environment variable from configuration files and > + initscripts, due to being unused. > + > ## [4.15.0 > UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0) > - TBD > > ### Added / support upgraded > > ~Andrew Olaf: View on the above? ~Andrew
[PATCH v4] tools/libs/store: cleanup libxenstore interface
There are some internals in the libxenstore interface which should be
removed.
Move those functions into xs_lib.c and the related definitions into
xs_lib.h. Remove the functions from the mapfile. Add xs_lib.o to
xenstore_client as some of the internal functions are needed there.
Bump the libxenstore version to 4.0 as the change is incompatible.
Note that the removed functions should not result in any problem as
they ought to be used by xenstored or xenstore_client only.
Avoid an enum as part of a structure as the size of an enum is
compiler implementation dependent.
Signed-off-by: Juergen Gross
---
V2: minimal variant (Ian Jackson)
V3: replace enum with unsigned int (Andrew Cooper)
V4: full variant again, this time with version bump (Ian Jackson)
---
tools/include/xenstore_lib.h | 54 ++
tools/libs/store/Makefile | 4 +-
tools/libs/store/libxenstore.map | 10 +--
tools/libs/store/xs.c | 112 +---
tools/xenstore/Makefile| 4 +-
tools/xenstore/utils.h | 11 +++
tools/xenstore/xenstore_client.c | 2 +
tools/xenstore/xenstored_control.c | 1 +
tools/xenstore/xenstored_core.c| 19 +++--
tools/xenstore/xenstored_core.h| 6 +-
tools/xenstore/xenstored_watch.c | 2 +-
tools/xenstore/xs_lib.c| 114 -
tools/xenstore/xs_lib.h| 50 +
tools/xenstore/xs_tdb_dump.c | 2 +-
14 files changed, 204 insertions(+), 187 deletions(-)
create mode 100644 tools/xenstore/xs_lib.h
diff --git a/tools/include/xenstore_lib.h b/tools/include/xenstore_lib.h
index 4c9b6d1685..2266009ec1 100644
--- a/tools/include/xenstore_lib.h
+++ b/tools/include/xenstore_lib.h
@@ -26,42 +26,26 @@
#include
#include
-/* Bitmask of permissions. */
-enum xs_perm_type {
- XS_PERM_NONE = 0,
- XS_PERM_READ = 1,
- XS_PERM_WRITE = 2,
- /* Internal use. */
- XS_PERM_ENOENT_OK = 4,
- XS_PERM_OWNER = 8,
- XS_PERM_IGNORE = 16,
-};
-
struct xs_permissions
{
unsigned int id;
- enum xs_perm_type perms;
-};
-
-/* Header of the node record in tdb. */
-struct xs_tdb_record_hdr {
- uint64_t generation;
- uint32_t num_perms;
- uint32_t datalen;
- uint32_t childlen;
- struct xs_permissions perms[0];
+ unsigned int perms; /* Bitmask of permissions. */
+#define XS_PERM_NONE 0x00
+#define XS_PERM_READ 0x01
+#define XS_PERM_WRITE 0x02
+ /* Internal use. */
+#define XS_PERM_ENOENT_OK 0x04
+#define XS_PERM_OWNER 0x08
+#define XS_PERM_IGNORE 0x10
};
/* Each 10 bits takes ~ 3 digits, plus one, plus one for nul terminator. */
#define MAX_STRLEN(x) ((sizeof(x) * CHAR_BIT + CHAR_BIT-1) / 10 * 3 + 2)
/* Path for various daemon things: env vars can override. */
-const char *xs_daemon_rootdir(void);
const char *xs_daemon_rundir(void);
const char *xs_daemon_socket(void);
const char *xs_daemon_socket_ro(void);
-const char *xs_domain_dev(void);
-const char *xs_daemon_tdb(void);
/* Simple write function: loops for you. */
bool xs_write_all(int fd, const void *data, unsigned int len);
@@ -70,26 +54,4 @@ bool xs_write_all(int fd, const void *data, unsigned int
len);
bool xs_strings_to_perms(struct xs_permissions *perms, unsigned int num,
const char *strings);
-/* Convert permissions to a string (up to len MAX_STRLEN(unsigned int)+1). */
-bool xs_perm_to_string(const struct xs_permissions *perm,
- char *buffer, size_t buf_len);
-
-/* Given a string and a length, count how many strings (nul terms). */
-unsigned int xs_count_strings(const char *strings, unsigned int len);
-
-/* Sanitising (quoting) possibly-binary strings. */
-struct expanding_buffer {
- char *buf;
- int avail;
-};
-
-/* Ensure that given expanding buffer has at least min_avail characters. */
-char *expanding_buffer_ensure(struct expanding_buffer *, int min_avail);
-
-/* sanitise_value() may return NULL if malloc fails. */
-char *sanitise_value(struct expanding_buffer *, const char *val, unsigned len);
-
-/* *out_len_r on entry is ignored; out must be at least strlen(in)+1 bytes. */
-void unsanitise_value(char *out, unsigned *out_len_r, const char *in);
-
#endif /* XENSTORE_LIB_H */
diff --git a/tools/libs/store/Makefile b/tools/libs/store/Makefile
index bee57b5629..43b018aa8c 100644
--- a/tools/libs/store/Makefile
+++ b/tools/libs/store/Makefile
@@ -1,8 +1,8 @@
XEN_ROOT=$(CURDIR)/../../..
include $(XEN_ROOT)/tools/Rules.mk
-MAJOR = 3.0
-MINOR = 3
+MAJOR = 4
+MINOR = 0
ifeq ($(CONFIG_Linux),y)
APPEND_LDFLAGS += -ldl
diff --git a/tools/libs/store/libxenstore.map b/tools/libs/store/libxenstore.map
index 9854305a2c..7e6c7bdd30 100644
--- a/tools/libs/store/libxenstore.map
+++ b/tools/libs/store/libxenstore.map
@@ -1,4 +1,4 @@
-VERS_3.0.3 {
+VERS_4.0 {
global:
xs_open;
Re: [PATCH RFCv2 03/15] xen/arm: p2m: Replace level_{orders, masks} arrays with LEVEL_{ORDER, MASK}
Hi Stefano, On 11/05/2021 23:33, Stefano Stabellini wrote: On Sun, 25 Apr 2021, Julien Grall wrote: From: Julien Grall The array level_orders and level_masks can be replaced with the recently introduced macros LEVEL_ORDER and LEVEL_MASK. Signed-off-by: Julien Grall So you actually planned to use LEVEL_ORDER and LEVEL_MASK in the xen/ code. I take back the previous comment :-) Is the 4KB size "hiding" (for the lack of a better word) done on purpose? Let me rephrase. Are you trying to consolidate info about pages being 4KB in xen/include/asm-arm/lpae.h ? THIRD_ORDER, SECOND_ORDER... is already not very 4KB specific :). In this case, what I am trying to do is completely removing the static arrays so they don't need to be global (or duplicated) when adding superpage support for Xen PT (see a follow-up patch). This also has the added benefits to replace a with a couple of loads with only a few instructions working on immediates. In any case: Acked-by: Stefano Stabellini Thank you! Cheers, -- Julien Grall
[ovmf test] 161912: all pass - PUSHED
flight 161912 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161912/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5531fd48ded1271b8775725355ab83994e4bc77c baseline version: ovmf 4e5ecdbac8bdf235b2072baa0c5e170cd9f57463 Last test of basis 161908 2021-05-11 16:40:04 Z0 days Testing same since 161912 2021-05-12 02:02:58 Z0 days1 attempts People who touched revisions under test: Lendacky, Thomas Sughosh Ganu Tom Lendacky 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 4e5ecdbac8..5531fd48de 5531fd48ded1271b8775725355ab83994e4bc77c -> xen-tested-master
Re: [PATCH RFCv2 02/15] xen/arm: lpae: Use the generic helpers to defined the Xen PT helpers
Hi Stefano,
On 11/05/2021 23:26, Stefano Stabellini wrote:
On Sun, 25 Apr 2021, Julien Grall wrote:
From: Julien Grall
Currently, Xen PT helpers are only working with 4KB page granularity
and open-code the generic helpers. To allow more flexibility, we can
re-use the generic helpers and pass Xen's page granularity
(PAGE_SHIFT).
As Xen PT helpers are used in both C and assembly, we need to move
the generic helpers definition outside of the !__ASSEMBLY__ section.
Note the aliases for each level are still kept for the time being so we
can avoid a massive patch to change all the callers.
Signed-off-by: Julien Grall
The patch is OK as is. I have a couple of suggestions for improvement
below. If you feel like making them, good, otherwise I am also OK if you
don't want to change anything.
---
Changes in v2:
- New patch
---
xen/include/asm-arm/lpae.h | 71 +-
1 file changed, 40 insertions(+), 31 deletions(-)
diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index 4fb9a40a4ca9..310f5225e056 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -159,6 +159,17 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned
int level)
#define lpae_get_mfn(pte)(_mfn((pte).walk.base))
#define lpae_set_mfn(pte, mfn) ((pte).walk.base = mfn_x(mfn))
+/* Generate an array @var containing the offset for each level from @addr */
+#define DECLARE_OFFSETS(var, addr) \
+const unsigned int var[4] = { \
+zeroeth_table_offset(addr), \
+first_table_offset(addr), \
+second_table_offset(addr), \
+third_table_offset(addr)\
+}
+
+#endif /* __ASSEMBLY__ */
+
/*
* AArch64 supports pages with different sizes (4K, 16K, and 64K).
* Provide a set of generic helpers that will compute various
@@ -190,17 +201,6 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned
int level)
#define LPAE_TABLE_INDEX_GS(gs, lvl, addr) \
(((addr) >> LEVEL_SHIFT_GS(gs, lvl)) & LPAE_ENTRY_MASK_GS(gs))
-/* Generate an array @var containing the offset for each level from @addr */
-#define DECLARE_OFFSETS(var, addr) \
-const unsigned int var[4] = { \
-zeroeth_table_offset(addr), \
-first_table_offset(addr), \
-second_table_offset(addr), \
-third_table_offset(addr)\
-}
-
-#endif /* __ASSEMBLY__ */
-
/*
* These numbers add up to a 48-bit input address space.
*
@@ -211,26 +211,35 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned
int level)
* therefore 39-bits are sufficient.
*/
-#define LPAE_SHIFT 9
-#define LPAE_ENTRIES(_AC(1,U) << LPAE_SHIFT)
-#define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
-
-#define THIRD_SHIFT(PAGE_SHIFT)
-#define THIRD_ORDER(THIRD_SHIFT - PAGE_SHIFT)
-#define THIRD_SIZE (_AT(paddr_t, 1) << THIRD_SHIFT)
-#define THIRD_MASK (~(THIRD_SIZE - 1))
-#define SECOND_SHIFT (THIRD_SHIFT + LPAE_SHIFT)
-#define SECOND_ORDER (SECOND_SHIFT - PAGE_SHIFT)
-#define SECOND_SIZE(_AT(paddr_t, 1) << SECOND_SHIFT)
-#define SECOND_MASK(~(SECOND_SIZE - 1))
-#define FIRST_SHIFT(SECOND_SHIFT + LPAE_SHIFT)
-#define FIRST_ORDER(FIRST_SHIFT - PAGE_SHIFT)
-#define FIRST_SIZE (_AT(paddr_t, 1) << FIRST_SHIFT)
-#define FIRST_MASK (~(FIRST_SIZE - 1))
-#define ZEROETH_SHIFT (FIRST_SHIFT + LPAE_SHIFT)
-#define ZEROETH_ORDER (ZEROETH_SHIFT - PAGE_SHIFT)
-#define ZEROETH_SIZE (_AT(paddr_t, 1) << ZEROETH_SHIFT)
-#define ZEROETH_MASK (~(ZEROETH_SIZE - 1))
Should we add a one-line in-code comment saying that the definitions
below are for 4KB pages? It is not immediately obvious any longer.
Because they are not meant to be for 4KB pages. They are meant to be for
Xen page size.
Today, it is always 4KB but I would like the Xen code to not rely on that.
I can clarify it in an in-code comment.
+#define LPAE_SHIFT LPAE_SHIFT_GS(PAGE_SHIFT)
+#define LPAE_ENTRIESLPAE_ENTRIES_GS(PAGE_SHIFT)
+#define LPAE_ENTRY_MASK LPAE_ENTRY_MASK_GS(PAGE_SHIFT)
+#define LEVEL_SHIFT(lvl)LEVEL_SHIFT_GS(PAGE_SHIFT, lvl)
+#define LEVEL_ORDER(lvl)LEVEL_ORDER_GS(PAGE_SHIFT, lvl)
+#define LEVEL_SIZE(lvl) LEVEL_SIZE_GS(PAGE_SHIFT, lvl)
+#define LEVEL_MASK(lvl) (~(LEVEL_SIZE(lvl) - 1))
I would avoid adding these 4 macros. It would be OK if they were just
used within this file but lpae.h is a header: they could end up be used
anywhere in the xen/ code and they have a very generic name. My
suggestion would be to skip them and just do:
Those macros will be used in follow-up patches. They are pretty useful
to avoid introduce static array with the different information for each
level.
Would prefix them with XEN_ be better?
#define THIRD_SHIFT LEVEL_SHIFT_GS(PAGE_SHIFT, 3)
etc.
+/* Convenience aliases */
+#define THIRD_SHIFT
Re: [PATCH 2/3] xen: Export dbgp functions when CONFIG_XEN_DOM0 is enabled
On 5/11/21 8:18 PM, Connor Davis wrote: > Export xen_dbgp_reset_prep and xen_dbgp_external_startup > when CONFIG_XEN_DOM0 is defined. This allows use of these symbols > even if CONFIG_EARLY_PRINK_DBGP is defined. > > Signed-off-by: Connor Davis > --- > drivers/xen/dbgp.c | 2 +- Unrelated to your patch but since you are fixing things around that file --- should we return -EPERM in xen_dbgp_op() when !xen_initial_domain()? -boris
Re: [PATCH v2 17/17] tools/ocaml/libs/mmap: Clean up unused read/write
On 11/05/2021 19:05, Edwin Török wrote: > diff --git a/tools/ocaml/libs/mmap/xenmmap.ml > b/tools/ocaml/libs/mmap/xenmmap.ml > index af258942a0..e17a62e607 100644 > --- a/tools/ocaml/libs/mmap/xenmmap.ml > +++ b/tools/ocaml/libs/mmap/xenmmap.ml > @@ -24,11 +24,6 @@ type mmap_map_flag = SHARED | PRIVATE > (* mmap: fd -> prot_flag -> map_flag -> length -> offset -> interface *) > external mmap': Unix.file_descr -> mmap_prot_flag -> mmap_map_flag > -> int -> int -> mmap_interface = "stub_mmap_init" > -(* read: interface -> start -> length -> data *) > -external read: mmap_interface -> int -> int -> string = "stub_mmap_read" > -(* write: interface -> data -> start -> length -> unit *) > -external write: mmap_interface -> string -> int -> int -> unit = > "stub_mmap_write" > -(* getpagesize: unit -> size of page *) > external unmap': mmap_interface -> unit = "stub_mmap_final" > (* getpagesize: unit -> size of page *) > let make ?(unmap=unmap') interface = interface, unmap Are comments supposed to be above or below the declaration? The double getpagesize and missing unmap comment looks like a copy mistake in the past. ~Andrew
Re: [PATCH v2 00/17] live update and gnttab patches
On 12/05/2021 11:10, Edwin Torok wrote: > On Tue, 2021-05-11 at 21:05 +0100, Andrew Cooper wrote: >> On 11/05/2021 19:05, Edwin Török wrote: >>> These patches have been posted previously. >>> The gnttab patches (tools/ocaml/libs/mmap) were not applied at the >>> time >>> to avoid conflicts with an in-progress XSA. >>> The binary format live-update and fuzzing patches were not applied >>> because it was too close to the next Xen release freeze. >>> >>> The patches depend on each-other: live-update only works correctly >>> when the gnttab >>> patches are taken too (MFN is not part of the binary live-update >>> stream), >>> so they are included here as a single series. >>> The gnttab patches replaces one use of libxenctrl with stable >>> interfaces, leaving one unstable >>> libxenctrl interface used by oxenstored. >>> >>> The 'vendor external dependencies' may be optional, it is useful to >>> be part >>> of a patchqueue in a specfile so that you can build everything >>> without external dependencies, >>> but might as well commit it so everyone has it easily available not >>> just XenServer. >>> >>> Note that the live-update fuzz test doesn't yet pass, it is still >>> able to find bugs. >>> However the reduced version with a fixed seed used as a unit test >>> does pass, >>> so it is useful to have it committed, and further improvements can >>> be made later >>> as more bugs are discovered and fixed. >>> >>> Edwin Török (17): >>> docs/designs/xenstore-migration.md: clarify that deletes are >>> recursive >>> tools/ocaml: add unit test skeleton with Dune build system >>> tools/ocaml: vendor external dependencies for convenience >>> tools/ocaml/xenstored: implement the live migration binary format >>> tools/ocaml/xenstored: add binary dump format support >>> tools/ocaml/xenstored: add support for binary format >>> tools/ocaml/xenstored: validate config file before live update >>> Add structured fuzzing unit test >>> tools/ocaml: use common macros for manipulating mmap_interface >>> tools/ocaml/libs/mmap: allocate correct number of bytes >>> tools/ocaml/libs/mmap: Expose stub_mmap_alloc >>> tools/ocaml/libs/mmap: mark mmap/munmap as blocking >>> tools/ocaml/libs/xb: import gnttab stubs from mirage >>> tools/ocaml: safer Xenmmap interface >>> tools/ocaml/xenstored: use gnttab instead of xenctrl's >>> foreign_map_range >>> tools/ocaml/xenstored: don't store domU's mfn of ring page >>> tools/ocaml/libs/mmap: Clean up unused read/write >> Gitlab CI reports failures across the board in Debian Stretch 32-bit >> builds. All logs >> https://gitlab.com/xen-project/patchew/xen/-/pipelines/301146112 but >> the >> tl;dr seems to be: >> >> File "disk.ml", line 179, characters 26-37: >> Error: Integer literal exceeds the range of representable integers of >> type int > Thanks, this should fix it, I refreshed my git tree (there is also a > fix there for the older version of Make): > https://gitlab.com/xen-project/patchew/xen/-/pipelines/301146112 > > Not sure whether it is worth continuing to support 32-bit i686 builds, > any modern Intel/AMD CPU would be 64-bit capable, but perhaps 32-bit is > still popular in the ARM world and keeping 32-bit Intel supported is > the easiest way to build-test it? Yes - arm32 is very much a thing, and currently 32bit userspace on x86 is a supported configuration. > > diff --git a/tools/ocaml/xenstored/disk.ml > b/tools/ocaml/xenstored/disk.ml > index 59794324e1..b7678af87f 100644 > --- a/tools/ocaml/xenstored/disk.ml > +++ b/tools/ocaml/xenstored/disk.ml > @@ -176,7 +176,7 @@ let write store = > output_byte ch i > > let w32 ch v = > - assert (v >= 0 && v <= 0x_); > + assert (v >= 0 && Int64.of_int v <= 0x_L); In the case that v is 32 bits wide, it will underflow and fail the v >= 0 check, before the upcast to Int64. ~Andrew
[linux-5.4 test] 161910: FAIL
flight 161910 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/161910/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken in 161905 build-arm64-xsm broken in 161905 build-arm64-pvopsbroken in 161905 build-arm644 host-install(4) broken in 161905 REGR. vs. 161832 build-arm64-xsm4 host-install(4) broken in 161905 REGR. vs. 161832 build-arm64-pvops 4 host-install(4) broken in 161905 REGR. vs. 161832 Tests which are failing intermittently (not blocking): test-amd64-amd64-examine 4 memdisk-try-append fail pass in 161905 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail pass in 161905 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked in 161905 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 161905 n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161832 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 161832 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161832 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 161832 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 161832 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 161832 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 161832 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 161832 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 161832 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 161832 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 161832 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl
[libvirt test] 161913: regressions - FAIL
flight 161913 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161913/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt 3976dc598ac8fa0689ab6bfc9e2de9b46d480055 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 306 days Failing since151818 2020-07-11 04:18:52 Z 305 days 298 attempts Testing same since 161913 2021-05-12 04:19:56 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Luke Yue Luyao Zhong Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle SeongHyun Jo Shalini Chellathurai Saroja Shaojun Yang Shi Lei simmon Simon Gaiser Stefan Bader Stefan Berger Stefan Berger Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Ville Skyttä Wang Xin WangJian Weblate Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yaroslav Kargin Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
[xen-unstable test] 161909: regressions - FAIL
flight 161909 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/161909/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken in 161904 build-arm64 broken in 161904 build-arm64-xsm broken in 161904 build-arm64-pvops 4 host-install(4) broken in 161904 REGR. vs. 161898 build-arm644 host-install(4) broken in 161904 REGR. vs. 161898 build-arm64-xsm4 host-install(4) broken in 161904 REGR. vs. 161898 test-arm64-arm64-examine 8 reboot fail REGR. vs. 161898 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl-thunderx 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 161898 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 161898 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 92 xtf/test-pv32pae-xsa-286 fail pass in 161904 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 161904 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 161904 n/a build-arm64-libvirt 1 build-check(1) blocked in 161904 n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161898 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 161898 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 161898 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 161898 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161898 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 161898 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 161898 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 161898 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 161898 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 161898 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 161898 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 161898 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail
Re: [PATCH v2 00/17] live update and gnttab patches
On Tue, 2021-05-11 at 21:05 +0100, Andrew Cooper wrote: > On 11/05/2021 19:05, Edwin Török wrote: > > These patches have been posted previously. > > The gnttab patches (tools/ocaml/libs/mmap) were not applied at the > > time > > to avoid conflicts with an in-progress XSA. > > The binary format live-update and fuzzing patches were not applied > > because it was too close to the next Xen release freeze. > > > > The patches depend on each-other: live-update only works correctly > > when the gnttab > > patches are taken too (MFN is not part of the binary live-update > > stream), > > so they are included here as a single series. > > The gnttab patches replaces one use of libxenctrl with stable > > interfaces, leaving one unstable > > libxenctrl interface used by oxenstored. > > > > The 'vendor external dependencies' may be optional, it is useful to > > be part > > of a patchqueue in a specfile so that you can build everything > > without external dependencies, > > but might as well commit it so everyone has it easily available not > > just XenServer. > > > > Note that the live-update fuzz test doesn't yet pass, it is still > > able to find bugs. > > However the reduced version with a fixed seed used as a unit test > > does pass, > > so it is useful to have it committed, and further improvements can > > be made later > > as more bugs are discovered and fixed. > > > > Edwin Török (17): > > docs/designs/xenstore-migration.md: clarify that deletes are > > recursive > > tools/ocaml: add unit test skeleton with Dune build system > > tools/ocaml: vendor external dependencies for convenience > > tools/ocaml/xenstored: implement the live migration binary format > > tools/ocaml/xenstored: add binary dump format support > > tools/ocaml/xenstored: add support for binary format > > tools/ocaml/xenstored: validate config file before live update > > Add structured fuzzing unit test > > tools/ocaml: use common macros for manipulating mmap_interface > > tools/ocaml/libs/mmap: allocate correct number of bytes > > tools/ocaml/libs/mmap: Expose stub_mmap_alloc > > tools/ocaml/libs/mmap: mark mmap/munmap as blocking > > tools/ocaml/libs/xb: import gnttab stubs from mirage > > tools/ocaml: safer Xenmmap interface > > tools/ocaml/xenstored: use gnttab instead of xenctrl's > > foreign_map_range > > tools/ocaml/xenstored: don't store domU's mfn of ring page > > tools/ocaml/libs/mmap: Clean up unused read/write > > Gitlab CI reports failures across the board in Debian Stretch 32-bit > builds. All logs > https://gitlab.com/xen-project/patchew/xen/-/pipelines/301146112 but > the > tl;dr seems to be: > > File "disk.ml", line 179, characters 26-37: > Error: Integer literal exceeds the range of representable integers of > type int Thanks, this should fix it, I refreshed my git tree (there is also a fix there for the older version of Make): https://gitlab.com/xen-project/patchew/xen/-/pipelines/301146112 Not sure whether it is worth continuing to support 32-bit i686 builds, any modern Intel/AMD CPU would be 64-bit capable, but perhaps 32-bit is still popular in the ARM world and keeping 32-bit Intel supported is the easiest way to build-test it? diff --git a/tools/ocaml/xenstored/disk.ml b/tools/ocaml/xenstored/disk.ml index 59794324e1..b7678af87f 100644 --- a/tools/ocaml/xenstored/disk.ml +++ b/tools/ocaml/xenstored/disk.ml @@ -176,7 +176,7 @@ let write store = output_byte ch i let w32 ch v = - assert (v >= 0 && v <= 0x_); + assert (v >= 0 && Int64.of_int v <= 0x_L); output_binary_int ch v let pos = pos_out @@ -213,7 +213,7 @@ let write store = let r32 t = (* read unsigned 32-bit int *) - let r = input_binary_int t land 0x_ in + let r = Int64.logand (Int64.of_int (input_binary_int t)) 0x_L |> Int64.to_int in assert (r >= 0); r @@ -293,7 +293,7 @@ module LiveRecord = struct write_record t Type.global_data 8 @@ fun b -> O.w32 b (FD.to_int rw_sock); (* TODO: this needs a unit test/live update test too! *) - O.w32 b 0x_ + O.w32 b 0x3FFF_ let read_global_data t ~len f = read_expect t "global_data" 8 len; > > ~Andrew
[xen-unstable-coverity test] 161916: all pass - PUSHED
flight 161916 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/161916/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen d4fb5f166c2bfbaf9ba0de69da0d411288f437a9 baseline version: xen a7da84c457b05479ab423a2e589c5f46c7da0ed7 Last test of basis 161877 2021-05-09 09:18:27 Z3 days Testing same since 161916 2021-05-12 09:19:39 Z0 days1 attempts People who touched revisions under test: Jason Andryuk Julien Grall Michal Orzel Olaf Hering Volodymyr Babchuk 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 a7da84c457..d4fb5f166c d4fb5f166c2bfbaf9ba0de69da0d411288f437a9 -> coverity-tested/smoke
Re: [PATCH v5 3/3] docs/doxygen: doxygen documentation for grant_table.h
> On 11 May 2021, at 22:58, Stefano Stabellini wrote: > > On Thu, 6 May 2021, Jan Beulich wrote: >> An alternative to correcting the (as it seems) v2 related issues, it >> may be worth considering to extract only v1 documentation in this >> initial phase. > > FWIW I agree with Jan that "grant table v1" documentation only is a good idea. Ok, I already pushed the v6: https://patchwork.kernel.org/project/xen-devel/cover/20210510084105.17108-1-luca.fance...@arm.com/
Re: [PATCH 1/2] xen/arm64: do not set SWIOTLB_NO_FORCE when swiotlb is required
> -int xen_swiotlb_detect(void)
> -{
> - if (!xen_domain())
> - return 0;
> - if (xen_feature(XENFEAT_direct_mapped))
> - return 1;
> - /* legacy case */
> - if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
> - return 1;
> - return 0;
> -}
I think this move should be a separate prep patch.
[qemu-mainline test] 161907: regressions - FAIL
flight 161907 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161907/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-i386-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-qemuu-freebsd12-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-freebsd10-i386 16 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-libvirt-pair 25 guest-start/debian fail REGR. vs. 152631 test-amd64-i386-freebsd10-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-libvirt-pair 25 guest-start/debian fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-saverestore fail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore fail REGR. vs. 152631 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 152631 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 152631 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 guest-start.2 fail REGR. vs. 152631 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check
Re: [PATCH 3/3] usb: xhci: Notify xen when DbC is unsafe to use
On Tue, May 11, 2021 at 06:18:21PM -0600, Connor Davis wrote: > When running as a dom0 guest on Xen, check if the USB3 debug > capability is enabled before xHCI reset, suspend, and resume. If it > is, call xen_dbgp_reset_prep() to notify Xen that it is unsafe to touch > MMIO registers until the next xen_dbgp_external_startup(). > > This notification allows Xen to avoid undefined behavior resulting > from MMIO access when the host controller's CNR bit is set or when > the device transitions to D3hot. > > Signed-off-by: Connor Davis > --- > drivers/usb/host/xhci-dbgcap.h | 6 > drivers/usb/host/xhci.c| 57 ++ > drivers/usb/host/xhci.h| 1 + > 3 files changed, 64 insertions(+) > > diff --git a/drivers/usb/host/xhci-dbgcap.h b/drivers/usb/host/xhci-dbgcap.h > index c70b78d504eb..24784b82a840 100644 > --- a/drivers/usb/host/xhci-dbgcap.h > +++ b/drivers/usb/host/xhci-dbgcap.h > @@ -227,4 +227,10 @@ static inline int xhci_dbc_resume(struct xhci_hcd *xhci) > return 0; > } > #endif /* CONFIG_USB_XHCI_DBGCAP */ > + > +#ifdef CONFIG_XEN_DOM0 > +int xen_dbgp_reset_prep(struct usb_hcd *hcd); > +int xen_dbgp_external_startup(struct usb_hcd *hcd); > +#endif /* CONFIG_XEN_DOM0 */ > + > #endif /* __LINUX_XHCI_DBGCAP_H */ > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index ca9385d22f68..afe44169183f 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -37,6 +37,57 @@ static unsigned long long quirks; > module_param(quirks, ullong, S_IRUGO); > MODULE_PARM_DESC(quirks, "Bit flags for quirks to be enabled as default"); > > +#ifdef CONFIG_XEN_DOM0 > +#include Can't this #ifdef stuff go into a .h file? thanks, greg k-h
Re: [PATCH v2 0/6] tools/libs: add missing support of linear p2m_list, cleanup
Ping?
On 12.04.21 17:22, Juergen Gross wrote:
There are some corners left which don't support the not so very new
linear p2m list of pv guests, which has been introduced in Linux kernel
3.19 and which is mandatory for non-legacy versions of Xen since kernel
4.14.
This series adds support for the linear p2m list where it is missing
(colo support and "xl dump-core").
In theory it should be possible to merge the p2m list mapping code
from migration handling and core dump handling, but this needs quite
some cleanup before this is possible.
The first three patches of this series are fixing real problems, so
I've put them at the start of this series, especially in order to make
backports easier.
The other three patches are only the first steps of cleanup. The main
work done here is to concentrate all p2m mapping in libxenguest instead
of having one implementation in each of libxenguest and libxenctrl.
Merging the two implementations should be rather easy, but this will
require to touch many lines of code, as the migration handling variant
seems to be more mature, but it is using the migration stream specific
structures heavily. So I'd like to have some confirmation that my way
to clean this up is the right one.
My idea would be to add the data needed for p2m mapping to struct
domain_info_context and replace the related fields in struct
xc_sr_context with a struct domain_info_context. Modifying the
interface of xc_core_arch_map_p2m() to take most current parameters
via struct domain_info_context would then enable migration coding to
use xc_core_arch_map_p2m() for mapping the p2m. xc_core_arch_map_p2m()
should look basically like the current migration p2m mapping code
afterwards.
Any comments to that plan?
Changes in V2:
- added missing #include in ocaml stub
Juergen Gross (6):
tools/libs/guest: fix max_pfn setting in map_p2m()
tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m
table
tools/libs/ctrl: use common p2m mapping code in xc_domain_resume_any()
tools/libs: move xc_resume.c to libxenguest
tools/libs: move xc_core* from libxenctrl to libxenguest
tools/libs/guest: make some definitions private to libxenguest
tools/include/xenctrl.h | 63 ---
tools/include/xenguest.h | 63 +++
tools/libs/ctrl/Makefile | 4 -
tools/libs/ctrl/xc_core_x86.c | 223 --
tools/libs/ctrl/xc_domain.c | 2 -
tools/libs/ctrl/xc_private.h | 43 +-
tools/libs/guest/Makefile | 4 +
.../libs/{ctrl/xc_core.c => guest/xg_core.c} | 7 +-
.../libs/{ctrl/xc_core.h => guest/xg_core.h} | 15 +-
.../xc_core_arm.c => guest/xg_core_arm.c} | 31 +-
.../xc_core_arm.h => guest/xg_core_arm.h} | 0
tools/libs/guest/xg_core_x86.c| 399 ++
.../xc_core_x86.h => guest/xg_core_x86.h} | 0
tools/libs/guest/xg_dom_boot.c| 2 +-
tools/libs/guest/xg_domain.c | 19 +-
tools/libs/guest/xg_offline_page.c| 2 +-
tools/libs/guest/xg_private.h | 16 +-
.../{ctrl/xc_resume.c => guest/xg_resume.c} | 69 +--
tools/libs/guest/xg_sr_save_x86_pv.c | 2 +-
tools/ocaml/libs/xc/xenctrl_stubs.c | 1 +
20 files changed, 545 insertions(+), 420 deletions(-)
delete mode 100644 tools/libs/ctrl/xc_core_x86.c
rename tools/libs/{ctrl/xc_core.c => guest/xg_core.c} (99%)
rename tools/libs/{ctrl/xc_core.h => guest/xg_core.h} (92%)
rename tools/libs/{ctrl/xc_core_arm.c => guest/xg_core_arm.c} (72%)
rename tools/libs/{ctrl/xc_core_arm.h => guest/xg_core_arm.h} (100%)
create mode 100644 tools/libs/guest/xg_core_x86.c
rename tools/libs/{ctrl/xc_core_x86.h => guest/xg_core_x86.h} (100%)
rename tools/libs/{ctrl/xc_resume.c => guest/xg_resume.c} (80%)
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
