[linux-5.4 test] 161503: tolerable FAIL - PUSHED

flight 161503 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/161503/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 161352 test-amd64-amd64-xl-qemut-win7-amd64

[qemu-mainline test] 161495: regressions - FAIL

flight 161495 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161495/ 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

[PATCH 10/12] golang/xenlight: add SendTrigger wrapper

Add a warpper around libxl_send_trigger. Signed-off-by: Nick Rosbrook --- tools/golang/xenlight/xenlight.go | 11 +++ 1 file changed, 11 insertions(+) diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go index 1e0ed109e4..d153feb851 100644 ---

[PATCH 12/12] golang/xenlight: add NotifyDomainDeath method to Context

Add a helper function to wait for domain death events, and then write the events to a provided channel. This handles the enabling/disabling of the event type, freeing the event, and converting it to a Go type. The caller can then handle the event however they need to. This function will run until

[PATCH 11/12] golang/xenlight: do not negate ret when converting to Error

There are several locations where the return code from calling into C is negated when being converted to Error. This results in error strings like "libxl error: ", rather than the correct message. Fix all occurrances of this by running: gofmt -w -r 'Error(-ret) -> Error(ret)' xenlight.go from

[PATCH 09/12] golang/xenlight: add DomainDestroy wrapper

Add a wrapper around libxl_domain_destroy. Signed-off-by: Nick Rosbrook --- tools/golang/xenlight/xenlight.go | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go index 65f93abe32..1e0ed109e4 100644 ---

[PATCH 08/12] golang/xenlight: add functional options to configure Context

Add a ContextOption type to support functional options in NewContext. Then, add a variadic ContextOption parameter to NewContext, which allows callers to specify 0 or more configuration options. For now, just add the WithLogLevel option so that callers can set the log level of the Context's

[PATCH 07/12] golang/xenlight: add logging conveniences for within xenlight

Add some logging methods to Context to provide easy use of the Contenxt's xentoollog_logger. These are not exported, but the LogLevel type is so that a later commit can allow the Context's log level to be configurable. Becuase cgo does not support calling C functions with variable arguments, e.g.

[PATCH 06/12] golang/xenlight: rename Ctx receivers to ctx

As a matter of style, it is strange to see capitalized receiver names, due to the significance of capitalized symbols in Go (although there is in fact nothing special about a capitalized receiver name). Fix this in xenlight.go by running: gofmt -w -r 'Ctx -> ctx' xenlight.go from

[PATCH 05/12] golang/xenlight: use struct pointers in keyed union fields

Currently, when marshalig Go types with keyed union fields, we assign the value of the struct (e.g. DomainBuildInfoTypeUnionHvm) which implements the interface of the keyed union field (e.g. DomainBuildInfoTypeUnion). As-is, this means that if a populated DomainBuildInfo is marshaled to e.g. JSON,

[PATCH 03/12] golang/xenlight: fix string conversion in generated toC functions

In gengotypes.py, the toC functions only set C string fields when the Go strings are non-empty. However, to prevent segfaults in some cases, these fields should always at least be set to nil so that the C memory is zeroed out. Update gengotypes.py so that the generated code always sets these

[PATCH 04/12] golang/xenlight: export keyed union interface types

For structs that have a keyed union, e.g. DomainBuildInfo, the TypeUnion field must be exported so that package users can get/set the fields within. This means that users are aware of the existence of the interface type used in those fields (see [1]), so it is awkward that the interface itself is

[PATCH 02/12] golang/xenlight: fix StringList toC conversion

The current implementation of StringList.toC does not correctly account for how libxl_string_list is expected to be laid out in C, which is clear when one looks at libxl_string_list_length in libxl.c. In particular, StringList.toC does not account for the extra memory that should be allocated for

[PATCH 00/12] golang/xenlight: domain life cycle support

The primary goal of this patch series is to allow users of the xenlight package to manage a full domain life cycle. In particular, it provides support for receiving domain death events so that domain shutdown, reboot, destroy, etc. can be handled. And, it addresses issues found when using the

[PATCH 01/12] golang/xenlight: update generated code

Re-generate code to reflect changes to libxl_types.idl from the following commits: 0570d7f276 x86/msr: introduce an option for compatible MSR behavior selection 7e5cffcd1e viridian: allow vCPU hotplug for Windows VMs 9835246710 viridian: remove implicit limit of 64 VPs per partition

[xen-unstable test] 161492: tolerable FAIL - PUSHED

flight 161492 xen-unstable real [real] flight 161510 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161492/ http://logs.test-lab.xenproject.org/osstest/logs/161510/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH RFCv2 12/15] xen/arm: add Persistent Map (PMAP) infrastructure

On Sun, Apr 25, 2021 at 09:13:15PM +0100, Julien Grall wrote: > From: Wei Liu > > The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We > pre-populate all the relevant page tables before the system is fully > set up. > > We will need it on Arm in order to rework the arm64 version of

Re: [PATCH 1/4] x86/xen/entry: Rename xenpv_exc_nmi to noist_exc_nmi

On Tue, 27 Apr 2021 07:09:46 +0800 Lai Jiangshan wrote: > From: Lai Jiangshan > > There is no any functionality change intended. Just rename it and > move it to arch/x86/kernel/nmi.c so that we can resue it later in > next patch for early NMI and kvm. Nit, but in change logs, please avoid

[libvirt test] 161496: regressions - FAIL

flight 161496 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161496/ 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

Serial Console : SOL vs Physical Port

Hello Guys, Is there any difference between both? I'm trying to debug an issue using a SOL but the host crashes before any meaningful message. The SOL is working properly when I can debug some crashes perfectly. But for a specific case I'm wondering if I could be losing some messages.

Re: [PATCH 0/5] Fix redefinition errors for toolstack libs

On 4/28/21 3:34 PM, Christian Lindig wrote: > > >> On 27 Apr 2021, at 13:05, Costin Lupu > > wrote: >> >> For replication I used gcc 10.3 on an Alpine system. In order to >> replicate the >> redefinition error for PAGE_SIZE one should install the 'fortify-headers'

Re: [PATCH 2/5] tools/libfsimage: Fix PATH_MAX redefinition error

On 4/28/21 12:04 PM, Julien Grall wrote: > > > On 27/04/2021 13:05, Costin Lupu wrote: >> If PATH_MAX is already defined in the system (e.g. in >> /usr/include/limits.h >> header) then gcc will trigger a redefinition error because of -Werror. >> >> Signed-off-by: Costin Lupu >> --- >>  

Re: [PATCH 3/5] tools/libs/foreignmemory: Fix PAGE_SIZE redefinition error

Hi Julien, On 4/28/21 12:03 PM, Julien Grall wrote: > Hi Costin, > > On 27/04/2021 13:05, Costin Lupu wrote: >>   tools/libs/foreignmemory/private.h | 6 -- >>   1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/tools/libs/foreignmemory/private.h >>

Re: [PATCH 1/3] x86/hvm: Introduce experimental guest CET support

On 28/04/2021 10:11, Jan Beulich wrote: > On 27.04.2021 19:39, Andrew Cooper wrote: >> On 27/04/2021 16:47, Jan Beulich wrote: >>> On 26.04.2021 19:54, Andrew Cooper wrote: --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -232,7

[linux-linus test] 161491: regressions - FAIL

flight 161491 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/161491/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332

Re: [SUSPECTED SPAM][RESEND PATCH 1/2] tools/libxl: Mark pointer args of many functions constant

On 28/04/2021 18:12, Anthony PERARD wrote: > On Fri, Dec 18, 2020 at 01:37:44PM -0800, Elliott Mitchell wrote: >> --- a/tools/libs/light/libxl_internal.h >> +++ b/tools/libs/light/libxl_internal.h >> @@ -2073,9 +2073,9 @@ struct libxl__xen_console_reader { >> /* parse the string @s as a sequence

Re: [SUSPECTED SPAM][RESEND PATCH 1/2] tools/libxl: Mark pointer args of many functions constant

On Fri, Dec 18, 2020 at 01:37:44PM -0800, Elliott Mitchell wrote: > --- a/tools/libs/light/libxl_internal.h > +++ b/tools/libs/light/libxl_internal.h > @@ -2073,9 +2073,9 @@ struct libxl__xen_console_reader { > /* parse the string @s as a sequence of 6 colon separated bytes in to @mac */ >

Re: [XEN PATCH 1/8] libxl: Replace deprecated QMP command by "query-cpus-fast"

On Fri, Apr 23, 2021 at 12:16 PM Anthony PERARD wrote: > > We use the deprecated QMP command "query-cpus" which is removed in the > QEMU 6.0 release. There's a replacement which is "query-cpus-fast", > and have been available since QEMU 2.12 (April 2018). > > This patch try the new command first

Re: [PATCH v2 21/21] libs/guest: (re)move xc_cpu_policy_apply_cpuid

On Tue, Apr 13, 2021 at 04:01:39PM +0200, Roger Pau Monne wrote: > diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c > index cadc8b2a05e..6be2d773d1d 100644 > --- a/tools/libs/light/libxl_cpuid.c > +++ b/tools/libs/light/libxl_cpuid.c > @@ -419,6 +419,136 @@ int >

Re: [PATCH v2 20/21] libs/{light,guest}: implement xc_cpuid_apply_policy in libxl

On Tue, Apr 13, 2021 at 04:01:38PM +0200, Roger Pau Monne wrote: > diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c > index 539fc4869e6..cadc8b2a05e 100644 > --- a/tools/libs/light/libxl_cpuid.c > +++ b/tools/libs/light/libxl_cpuid.c > @@ -436,6 +438,42 @@ int

[xen-4.12-testing test] 161489: regressions - FAIL

flight 161489 xen-4.12-testing real [real] flight 161506 xen-4.12-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161489/ http://logs.test-lab.xenproject.org/osstest/logs/161506/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

Re: [PATCH v2 01/21] libxl: don't ignore the return value from xc_cpuid_apply_policy

On Tue, Apr 13, 2021 at 04:01:19PM +0200, Roger Pau Monne wrote: > Also change libxl__cpuid_legacy to propagate the error from > xc_cpuid_apply_policy into callers. > > Signed-off-by: Roger Pau Monné > Reviewed-by: Jan Beulich > --- > Changes since 1: > - Return ERROR_FAIL on error. > --- >

[qemu-mainline bisection] complete test-armhf-armhf-libvirt

branch xen-unstable xenbranch xen-unstable job test-armhf-armhf-libvirt testid guest-start Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware

Re: [PATCH v3 3/3] docs/doxygen: doxygen documentation for grant_table.h

> On 27 Apr 2021, at 14:57, Jan Beulich wrote: > > On 26.04.2021 17:37, Luca Fancellu wrote: >> --- a/docs/hypercall-interfaces/arm64.rst >> +++ b/docs/hypercall-interfaces/arm64.rst >> @@ -8,6 +8,7 @@ Starting points >> .. toctree:: >>:maxdepth: 2 >> >> + arm64/grant_tables >> >> >>

Re: [PATCH v3 3/3] xen/pci: Refactor MSI code that implements MSI functionality within XEN

On 28/04/2021 12:06, Roger Pau Monné wrote: On Mon, Apr 26, 2021 at 05:21:27PM +0100, Rahul Singh wrote: MSI code that implements MSI functionality to support MSI within XEN is not usable on ARM. Move the code under CONFIG_PCI_MSI_INTERCEPT flag to gate the code for ARM. Currently, we have

Re: [PATCH 2/3] x86/svm: Enumeration for CET

On 28/04/2021 10:14, Jan Beulich wrote: > On 27.04.2021 19:47, Andrew Cooper wrote: >> On 27/04/2021 16:53, Jan Beulich wrote: >>> On 26.04.2021 19:54, Andrew Cooper wrote: @@ -497,7 +501,9 @@ struct vmcb_struct { u64 rip; u64 res14[11]; u64 rsp; -u64

Re: [PATCH v3 3/3] xen/pci: Refactor MSI code that implements MSI functionality within XEN

On 28.04.2021 13:06, Roger Pau Monné wrote: > On Mon, Apr 26, 2021 at 05:21:27PM +0100, Rahul Singh wrote: >> MSI code that implements MSI functionality to support MSI within XEN is >> not usable on ARM. Move the code under CONFIG_PCI_MSI_INTERCEPT flag to >> gate the code for ARM. >> >>

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

On 26.04.2021 18:21, Rahul Singh wrote: > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -21,7 +21,7 @@ > #include > #include > #include > -#ifdef CONFIG_HAS_PCI > +#ifdef CONFIG_PCI_MSI_INTERCEPT > #include > #endif > #include > @@ -114,7 +114,7 @@ static int

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

On 28.04.2021 12:42, Roger Pau Monné wrote: > On Mon, Apr 26, 2021 at 05:21:26PM +0100, Rahul Singh wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -20,6 +20,7 @@ config X86 >> select HAS_NS16550 >> select HAS_PASSTHROUGH >> select HAS_PCI >> +select

Re: [PATCH RESEND v3 3/3] arm,smmu: add support for generic DT bindings. Implement add_device and dt_xlate.

On 13/04/2021 18:59, Stefano Stabellini wrote: From: Brian Woods Now that all arm iommu drivers support generic bindings we can remove the workaround from iommu_add_dt_device(). Well, it was just added in a different place in patch #1. ;) I have commented about it in patch #1. Note

Re: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map

On 28.04.2021 15:22, Hongyan Xia wrote: > On Wed, 2021-04-28 at 13:51 +0200, Jan Beulich wrote: >> See my proposal to defer unmapping of the domain's own pages >> (and I would consider the p2m pages to be part of the domain's >> ones for this purpose). In fact, since the p2m pages come from a >>

Re: [PATCH RESEND v3 2/3] arm,smmu: restructure code in preparation to new bindings support

Hi Stefano, On 13/04/2021 18:59, Stefano Stabellini wrote: From: Brian Woods Restructure some of the code and add supporting functions for adding generic device tree (DT) binding support. This will allow for using current Linux device trees with just modifying the chosen field to enable Xen.

Re: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map

On Wed, 2021-04-28 at 13:51 +0200, Jan Beulich wrote: > On 28.04.2021 13:04, Hongyan Xia wrote: > > On Thu, 2021-04-22 at 14:31 +0200, Jan Beulich wrote: > > > As I don't think we have many cases where code actually depends > > > on > > > being able to apply __va() (or equivalent) to the address >

Re: [PATCH RESEND v3 1/3] arm,smmu: switch to using iommu_fwspec functions

Hi Stefano, On 13/04/2021 18:59, Stefano Stabellini wrote: From: Brian Woods Modify the smmu driver so that it uses the iommu_fwspec helper functions. This means both ARM IOMMU drivers will both use the iommu_fwspec helper functions, making enabling generic device tree bindings in the SMMU

Re: [PATCH 0/3] x86: Initial pieces for guest CET support

On 28.04.2021 14:25, Andrew Cooper wrote: > On 27/04/2021 11:13, Andrew Cooper wrote: >> There are 3 emulator complexities for shadow stack instructions.  SSP >> itself as a register, WRUSS no longer being CPL-based for >> user/supervisor, and the fact that RSTORSSP in particular uses an atomic >>

Re: [XEN PATCH] xl: constify cmd_table entries

NIT: I would suggest to add "..." so it is clear... On 27/04/2021 17:11, Anthony PERARD wrote: and cmdtable_len. ... this is a continuation of the title. The entries in cmd_table don't need to be modified once xl is running. Signed-off-by: Anthony PERARD --- tools/xl/xl.c | 4

Re: obtain a list of granttable PFNs from toolstack

Am Wed, 28 Apr 2021 12:43:45 +0100 schrieb Andrew Cooper : > Grants are not properly accounted for in the logdirty bitmap, because > they're not unmapped during the final phase. Yeah, which means the verify code can do no useful work. This can be addressed by either removing it. Or by giving

Re: Discussion of Xenheap problems on AArch64

On 28/04/2021 10:28, Henry Wang wrote: Hi Julien, Hi Henry, I've done some test about the patch series in https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/pt/rfc-v2 Thanks you for the testing. Some questions below. Log: (XEN) VTCR_EL2:

Re: [PATCH 0/5] Fix redefinition errors for toolstack libs

On 27 Apr 2021, at 13:05, Costin Lupu mailto:costin.l...@cs.pub.ro>> wrote: For replication I used gcc 10.3 on an Alpine system. In order to replicate the redefinition error for PAGE_SIZE one should install the 'fortify-headers' package which will change the chain of included headers by

Re: [RFC PATCH 0/2] libxl: support common cases without block script

On Wed, Apr 28, 2021 at 3:00 AM Demi Marie Obenour wrote: > > When it comes to file-based block devices, the major difficulty is > the extremely bad kernel API. The only fully safe way to use loop > devices is to use LOOP_CONFIGURE with LO_FLAGS_AUTOCLEAR and hold a > file descriptor open to the

Re: [PATCH 0/3] x86: Initial pieces for guest CET support

On 27/04/2021 11:13, Andrew Cooper wrote: > There are 3 emulator complexities for shadow stack instructions.  SSP > itself as a register, WRUSS no longer being CPL-based for > user/supervisor, and the fact that RSTORSSP in particular uses an atomic > block which microcode can express, but can't be

Re: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map

On 28.04.2021 13:04, Hongyan Xia wrote: > On Thu, 2021-04-22 at 14:31 +0200, Jan Beulich wrote: >> As I don't think we have many cases where code actually depends on >> being able to apply __va() (or equivalent) to the address returned >> from alloc_xenheap_pages(), I think this should instead

Re: obtain a list of granttable PFNs from toolstack

On 28/04/2021 12:03, Olaf Hering wrote: > Am Wed, 28 Apr 2021 12:42:54 +0200 > schrieb Jan Beulich : > >> It might help if you would outline what you're actually after by >> knowing a domain's active grants. > There is REC_TYPE_VERIFY, which will re-transmit all memory of a paused domU > and

Re: obtain a list of granttable PFNs from toolstack

On 28/04/2021 11:17, Olaf Hering wrote: > Am Wed, 28 Apr 2021 11:49:59 +0200 > schrieb Jan Beulich : > >> On 28.04.2021 09:50, Olaf Hering wrote: >>> Is there an API to get a list of PFNs which are currently being active in >>> the grant table for a given domid? >> Do you really mean PFNs? >

Re: [PATCH v3 3/3] xen/pci: Refactor MSI code that implements MSI functionality within XEN

On Mon, Apr 26, 2021 at 05:21:27PM +0100, Rahul Singh wrote: > MSI code that implements MSI functionality to support MSI within XEN is > not usable on ARM. Move the code under CONFIG_PCI_MSI_INTERCEPT flag to > gate the code for ARM. > > Currently, we have no idea how MSI functionality will be

Re: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map

On Thu, 2021-04-22 at 14:31 +0200, Jan Beulich wrote: > On 30.04.2020 22:44, Hongyan Xia wrote: > > From: Hongyan Xia > > > > When there is not an always-mapped direct map, xenheap allocations > > need > > to be mapped and unmapped on-demand. > > > > Signed-off-by: Hongyan Xia > > This series

Re: obtain a list of granttable PFNs from toolstack

Am Wed, 28 Apr 2021 12:42:54 +0200 schrieb Jan Beulich : > It might help if you would outline what you're actually after by > knowing a domain's active grants. There is REC_TYPE_VERIFY, which will re-transmit all memory of a paused domU and compare what was previously transferred. Last time I

Re: [PATCH v3 2/3] xen/pci: Refactor PCI MSI intercept related code

On Mon, Apr 26, 2021 at 05:21:26PM +0100, Rahul Singh wrote: > MSI intercept related code is not useful for ARM when MSI interrupts are > injected via GICv3 ITS. > > Therefore introducing the new flag CONFIG_PCI_MSI_INTERCEPT to gate the > MSI code for ARM in common code and also implemented the

Re: obtain a list of granttable PFNs from toolstack

On 28.04.2021 12:17, Olaf Hering wrote: > Am Wed, 28 Apr 2021 11:49:59 +0200 > schrieb Jan Beulich : >> On 28.04.2021 09:50, Olaf Hering wrote: >>> Is there an API to get a list of PFNs which are currently being active in >>> the grant table for a given domid? >> >> Also, what do you mean by

Re: obtain a list of granttable PFNs from toolstack

Am Wed, 28 Apr 2021 11:49:59 +0200 schrieb Jan Beulich : > On 28.04.2021 09:50, Olaf Hering wrote: > > Is there an API to get a list of PFNs which are currently being active in > > the grant table for a given domid? > Do you really mean PFNs? The save/restore code uses the term "pfn" to refer

Re: [PATCH 00/16] Remove the direct map

On Tue, 2020-06-02 at 09:08 +, Wei Liu wrote: > On Fri, May 01, 2020 at 02:53:08PM +0100, Hongyan Xia wrote: [...] > Not sure about hiding EPT. I will leave this question to Jan and > Andrew... Quick update on performance numbers. I have seen noticeable performance drop if we need to map

[xen-unstable-coverity test] 161502: all pass - PUSHED

flight 161502 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/161502/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 972ba1d1d4bcb77018b50fd2bb63c0e628859ed3 baseline version: xen

Re: [xen-unstable test] 161480: regressions - FAIL

On 28.04.2021 00:58, osstest service owner wrote: > flight 161480 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/161480/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-arm64 6

Re: [PATCH v5 05/16] swiotlb: Add restricted DMA pool initialization

On 26/04/2021 17:37, Claire Chang wrote: On Fri, Apr 23, 2021 at 7:34 PM Steven Price wrote: [...] But even then if it's not and we have the situation where debugfs==NULL then the debugfs_create_dir() here will cause a subsequent attempt in swiotlb_create_debugfs() to fail (directory already

Re: obtain a list of granttable PFNs from toolstack

On 28.04.2021 09:50, Olaf Hering wrote: > Is there an API to get a list of PFNs which are currently being active in the > grant table for a given domid? Do you really mean PFNs? For PV, the P <=> M relationship is guest-managed, and hence any value returned here would be stale by the time the

Re: [PATCH 2/7] x86: introduce ioremap_wc()

On 27.04.2021 19:13, Andrew Cooper wrote: > On 27/04/2021 13:54, Jan Beulich wrote: >> In order for a to-be-introduced ERMS form of memcpy() to not regress >> boot performance on certain systems when video output is active, we >> first need to arrange for avoiding further dependency on firmware >>

RE: Discussion of Xenheap problems on AArch64

Hi Julien, I've done some test about the patch series in https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/pt/rfc-v2 If you have time, could you please take a look at the inline test result and kindly inform if I tested the patch series correctly? Thanks!

Re: [PATCH 3/3] x86/VT-x: Enumeration for CET

On 27.04.2021 18:27, Andrew Cooper wrote: > On 27/04/2021 16:56, Jan Beulich wrote: >> On 26.04.2021 19:54, Andrew Cooper wrote: >>> VT-x has separate entry/exit control for loading guest/host state. Saving >>> guest state on vmexit is performed unconditionally. >> With the latter I find ... >>

Re: [PATCH 2/3] x86/svm: Enumeration for CET

On 27.04.2021 19:47, Andrew Cooper wrote: > On 27/04/2021 16:53, Jan Beulich wrote: >> On 26.04.2021 19:54, Andrew Cooper wrote: >>> @@ -497,7 +501,9 @@ struct vmcb_struct { >>> u64 rip; >>> u64 res14[11]; >>> u64 rsp; >>> -u64 res15[3]; >>> +u64 _msr_s_cet; /*

Re: [PATCH 1/3] x86/hvm: Introduce experimental guest CET support

On 27.04.2021 19:39, Andrew Cooper wrote: > On 27/04/2021 16:47, Jan Beulich wrote: >> On 26.04.2021 19:54, Andrew Cooper wrote: >>> --- a/xen/include/public/arch-x86/cpufeatureset.h >>> +++ b/xen/include/public/arch-x86/cpufeatureset.h >>> @@ -232,7 +232,7 @@ XEN_CPUFEATURE(UMIP, 6*32+

Re: [PATCH 2/5] tools/libfsimage: Fix PATH_MAX redefinition error

On 27/04/2021 13:05, Costin Lupu wrote: If PATH_MAX is already defined in the system (e.g. in /usr/include/limits.h header) then gcc will trigger a redefinition error because of -Werror. Signed-off-by: Costin Lupu --- tools/libfsimage/ext2fs/fsys_ext2fs.c | 2 ++

Re: [PATCH 3/5] tools/libs/foreignmemory: Fix PAGE_SIZE redefinition error

Hi Costin, On 27/04/2021 13:05, Costin Lupu wrote: tools/libs/foreignmemory/private.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/libs/foreignmemory/private.h b/tools/libs/foreignmemory/private.h index 1ee3626dd2..f3c1ba2867 100644 ---

Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

On 28/04/2021 09:49, Jan Beulich wrote: On 28.04.2021 09:19, Paul Durrant wrote: On 28/04/2021 07:15, Jan Beulich wrote: Following the extension to the command line option I'm putting in place in "IOMMU: make DMA containment of quarantined devices optional" (which I still need to get around to

Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

On 28.04.2021 09:19, Paul Durrant wrote: > On 28/04/2021 07:15, Jan Beulich wrote: >> Following the extension to the command line option I'm putting in place >> in "IOMMU: make DMA containment of quarantined devices optional" (which >> I still need to get around to address review feedback for and

Re: [PATCH] x86/emul: Use existing X86_EXC_* constants

On 27.04.2021 20:56, Andrew Cooper wrote: > On 27/04/2021 08:09, Jan Beulich wrote: >> On 26.04.2021 14:45, Andrew Cooper wrote: >>> ... rather than having separate definitions locally. EXC_HAS_EC in >>> particular >>> is missing #CP, #VC and #SX vs X86_EXC_HAVE_EC. >>> >>> Also switch a raw 14

Re: [PATCH] x86/pv: Drop HYPERVISOR_COMPAT_VIRT_START()

On 27.04.2021 20:05, Andrew Cooper wrote: > On 27/04/2021 14:18, Jan Beulich wrote: >> On 27.04.2021 15:02, Andrew Cooper wrote: >>> --- a/xen/include/asm-x86/config.h >>> +++ b/xen/include/asm-x86/config.h >>> @@ -254,21 +254,16 @@ extern unsigned char boot_edid_info[128]; >>> >>> /* This is

obtain a list of granttable PFNs from toolstack

Is there an API to get a list of PFNs which are currently being active in the grant table for a given domid? Olaf pgpSEQrEmU4T7.pgp Description: Digitale Signatur von OpenPGP

Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

On 28/04/2021 07:15, Jan Beulich wrote: On 28.04.2021 00:00, Scott Davis wrote: On 4/27/21, 2:56 AM, Jan Beulich wrote: On 26.04.2021 19:25, Scott Davis wrote: This patch modifies Xen's behavior when making devices assignable while the iommu=no-quarantine command line option is in effect.

Re: [RFC PATCH 0/2] libxl: support common cases without block script

When it comes to file-based block devices, the major difficulty is the extremely bad kernel API. The only fully safe way to use loop devices is to use LOOP_CONFIGURE with LO_FLAGS_AUTOCLEAR and hold a file descriptor open to the device until another piece of code (either another userspace program

[xen-4.14-testing test] 161484: tolerable FAIL - PUSHED

flight 161484 xen-4.14-testing real [real] flight 161498 xen-4.14-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161484/ http://logs.test-lab.xenproject.org/osstest/logs/161498/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

On 28.04.2021 00:00, Scott Davis wrote: > On 4/27/21, 2:56 AM, Jan Beulich wrote: >> On 26.04.2021 19:25, Scott Davis wrote: >>> This patch modifies Xen's behavior when making devices assignable while the >>> iommu=no-quarantine command line option is in effect. Currently this option >>> only

Re: [PATCH v3] x86/oprofile: remove compat accessors usage from backtrace

On 27.04.2021 20:09, Roger Pau Monné wrote: > On Tue, Apr 27, 2021 at 05:31:25PM +0200, Jan Beulich wrote: >> On 27.04.2021 16:21, Roger Pau Monne wrote: >>> Remove the unneeded usage of the compat layer to copy frame pointers >>> from guest address space. Instead just use raw_copy_from_guest. >>>

Re: [PATCH v3] x86/oprofile: remove compat accessors usage from backtrace

On 27.04.2021 20:07, Roger Pau Monné wrote: > On Tue, Apr 27, 2021 at 05:37:22PM +0200, Jan Beulich wrote: >> On 27.04.2021 16:21, Roger Pau Monne wrote: >>> Remove the unneeded usage of the compat layer to copy frame pointers >>> from guest address space. Instead just use raw_copy_from_guest. >>>