[Xen-devel] [libvirt test] 146410: regressions - FAIL

flight 146410 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/146410/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt

[Xen-devel] [qemu-mainline test] 146409: regressions - FAIL

flight 146409 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146409/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

[Xen-devel] [linux-5.4 test] 146398: regressions - FAIL

flight 146398 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146398/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On Wed, Jan 22, 2020 at 04:27:39PM +, Lars Kurth wrote: > > You should also leverage the developer summit: see > https://events.linuxfoundation.org/xen-summit/program/cfp/ > > CfP closes March 6th. Design sessions can be submitted

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On Wed, Jan 22, 2020 at 02:57:47PM +, Andrew Cooper wrote: > How much time do you have to put towards the port?  Is this something in > your free time, or something you are doing as part of work?  Ultimately, > we are going to need to increase the level of RISC-V knowledge in the > community

[Xen-devel] [ovmf test] 146405: regressions - FAIL

flight 146405 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146405/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On Wed, Jan 22, 2020 at 01:05:11PM -0800, Stefano Stabellini wrote: > On Wed, 22 Jan 2020, Andrew Cooper wrote: > > > My big questions are: > > > Does the Xen project have interest in RISC-V? > > > > There is very large downstream interest in RISC-V.  So a definite yes. > > Definite Yes from

[Xen-devel] [libvirt bisection] complete build-armhf-libvirt

branch xen-unstable xenbranch xen-unstable job build-armhf-libvirt testid libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/ Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: ovmf

[Xen-devel] [qemu-mainline test] 146403: regressions - FAIL

flight 146403 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146403/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

[Xen-devel] [xen-unstable test] 146393: regressions - FAIL

flight 146393 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146393/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs.

Re: [Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page

From: Wei Liu On Behalf Of Wei Liu Sent: Wednesday, January 22, 2020 12:24 PM > > Use the top-most addressable page for that purpose. Adjust e820 code > accordingly. > > We also need to register Xen's guest OS ID to Hyper-V. Use 0x300 as the > OS type. > > Signed-off-by: Wei Liu > --- > XXX

[Xen-devel] [xen-unstable-smoke test] 146401: tolerable all pass - PUSHED

flight 146401 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146401/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[Xen-devel] [ovmf test] 146395: regressions - FAIL

flight 146395 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146395/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

Re: [Xen-devel] libvirt support for scheduler credit2

On 1/22/20 12:56 PM, Jim Fehlig wrote: > On 1/21/20 10:05 AM, Jürgen Groß wrote: >> On 21.01.20 17:56, Kevin Stange wrote: >>> Hi, >>> >>> I looked around a bit and wasn't able to find a good answer to this, so >>> George suggested I ask here. >> >> Cc-ing Jim. >> >>> >>> Since Xen 4.12, credit2

[Xen-devel] [qemu-mainline test] 146400: regressions - FAIL

flight 146400 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146400/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

Re: [Xen-devel] [PATCH v2 1/4] x86/microcode: Improve documentation and parsing for ucode=

On 21.01.20 21:51, Eslam Elnikety wrote: On 21.01.20 10:27, Jan Beulich wrote: On 21.01.2020 00:50, Eslam Elnikety wrote: On 20.01.20 09:42, Jan Beulich wrote: On 17.01.2020 20:06, Eslam Elnikety wrote: On 20.12.19 10:53, Jan Beulich wrote: On 19.12.2019 22:08, Eslam Elnikety wrote: On

[Xen-devel] [PATCH v1 4/4] x86/microcode: use const qualifier for microcode buffer

The buffer holding the microcode bits should be marked as const. Signed-off-by: Eslam Elnikety Acked-by: Jan Beulich --- xen/arch/x86/microcode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c index

[Xen-devel] [PATCH v1 1/4] x86/microcode: Improve documentation for ucode=

Specify applicability and the default value. Also state that, in case of EFI, the microcode update blob specified in the EFI cfg takes precedence over `ucode=scan`, if the latter is specified on Xen commend line. No functional changes. Signed-off-by: Eslam Elnikety ---

[Xen-devel] [PATCH v1 0/4] x86/microcode: Improve documentation and code

This patch series introduces improvements to the existing documentation and code of x86/microcode. Patches 1 and 2 improve the documentation and parsing for `ucode=`. Patches 3 and 4 introduce nits/improvements to the microcode early loading code. Some (variant of the) patches have been sent

[Xen-devel] [PATCH v1 3/4] x86/microcode: avoid unnecessary xmalloc/memcpy of ucode data

When using `ucode=scan` and if a matching module is found, the microcode payload is maintained in an xmalloc()'d region. This is unnecessary since the bootmap would just do. Remove the xmalloc and xfree on the microcode module scan path. This commit also does away with the restriction on the

[Xen-devel] [PATCH v1 2/4] x86/microcode: Improve parsing for ucode=

Decouple the microcode indexing mechanism when using GRUB to that when using EFI. This allows us to avoid the "unspecified effect" of using `` when booting via EFI. With that, Xen can explicitly ignore that option when using EFI. This is the only functinal change this commit introduces. Update the

[Xen-devel] [xen-unstable-smoke test] 146396: tolerable all pass - PUSHED

flight 146396 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146396/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v4 7/7] x86/hyperv: setup VP assist page

On 22/01/2020 20:23, Wei Liu wrote: > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c > b/xen/arch/x86/guest/hyperv/hyperv.c > index 085e646dc6..89a8f316b2 100644 > --- a/xen/arch/x86/guest/hyperv/hyperv.c > +++ b/xen/arch/x86/guest/hyperv/hyperv.c > @@ -32,6 +32,7 @@ > struct ms_hyperv_info

Re: [Xen-devel] [PATCH v4 3/7] x86/hyperv: provide Hyper-V hypercall functions

On 22/01/2020 20:23, Wei Liu wrote: > These functions will be used later to make hypercalls to Hyper-V. > > Signed-off-by: Wei Liu After some experimentation, diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index cbc5701214..3708a60b5c 100644 --- a/xen/arch/x86/xen.lds.S +++

[Xen-devel] [qemu-mainline test] 146397: regressions - FAIL

flight 146397 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146397/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

Re: [Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page

On 22/01/2020 20:23, Wei Liu wrote: > Use the top-most addressable page for that purpose. Adjust e820 code > accordingly. > > We also need to register Xen's guest OS ID to Hyper-V. Use 0x300 as the > OS type. > > Signed-off-by: Wei Liu > --- > XXX the decision on Xen's vendor ID is pending.

Re: [Xen-devel] [Vote] For Xen Project Code of Conduct (deadline March 31st)

On Fri, 17 Jan 2020, Lars Kurth wrote: > Hi all, > > for some time now we have been discussing the Xen Project Code of > Conduct. The most recent set of feedback has been primarily around > minor language issues (US vs UL English, etc.), which indicates to me > that the proposal is ready to be

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On Wed, 22 Jan 2020, Andrew Cooper wrote: > > My big questions are: > > Does the Xen project have interest in RISC-V? > > There is very large downstream interest in RISC-V.  So a definite yes. Definite Yes from me too > > What can be done to make the RISC-V port as upstreamable as > >

Re: [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility

On 22/01/2020 20:23, Wei Liu wrote: > diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S > index 1cbf5acdfb..605d01f1dd 100644 > --- a/xen/arch/x86/boot/x86_64.S > +++ b/xen/arch/x86/boot/x86_64.S > @@ -85,7 +85,15 @@ GLOBAL(l2_directmap) > * 4k page. > */ Adjust this

[Xen-devel] [PATCH v4 5/7] x86/hyperv: provide percpu hypercall input page

Hyper-V's input / output argument must be 8 bytes aligned an not cross page boundary. One way to satisfy those requirements is to use percpu page. For the foreseeable future we only need to provide input for TLB and APIC hypercalls, so skip setting up an output page. We will also need to provide

[Xen-devel] [PATCH v4 7/7] x86/hyperv: setup VP assist page

VP assist page is rather important as we need to toggle some bits in it for efficient nested virtualisation. Signed-off-by: Wei Liu --- v4: 1. Use private.h 2. Prevent leak v3: 1. Use xenheap page 2. Drop set_vp_assist v2: 1. Use HV_HYP_PAGE_SHIFT instead ---

[Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility

This allows us to set aside some address space for executable mapping. This fixed map range starts from XEN_VIRT_END so that it is within reach of the .text section. Shift the percpu stub range and livepatch range accordingly. Signed-off-by: Wei Liu --- xen/arch/x86/boot/x86_64.S | 10

[Xen-devel] [PATCH v4 0/7] More Hyper-V infrastructure

This patch sereis implements several important functionalities to run Xen on top of Hyper-V. See individual patches for more details. The first patch adds an executable fixmap facility, which is x86 generic. The rest of the series is Hyper-V specific. I've checked the assembly code as well as

[Xen-devel] [PATCH v4 3/7] x86/hyperv: provide Hyper-V hypercall functions

These functions will be used later to make hypercalls to Hyper-V. Signed-off-by: Wei Liu --- v4: 1. Adjust code due to previous patch has changed 2. Address comments --- xen/include/asm-x86/guest/hyperv-hcall.h | 98 1 file changed, 98 insertions(+) create mode 100644

[Xen-devel] [PATCH v4 4/7] DO NOT APPLY: x86/hyperv: issue an hypercall

Test if the infrastructure works. Signed-off-by: Wei Liu --- xen/arch/x86/guest/hyperv/hyperv.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/xen/arch/x86/guest/hyperv/hyperv.c b/xen/arch/x86/guest/hyperv/hyperv.c index f986c1a805..536ce0d0dd 100644 ---

[Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page

Use the top-most addressable page for that purpose. Adjust e820 code accordingly. We also need to register Xen's guest OS ID to Hyper-V. Use 0x300 as the OS type. Signed-off-by: Wei Liu --- XXX the decision on Xen's vendor ID is pending. v4: 1. Use fixmap 2. Follow routines listed in TLFS ---

[Xen-devel] [PATCH v4 6/7] x86/hyperv: retrieve vp_index from Hyper-V

This will be useful when invoking hypercall that targets specific vcpu(s). Signed-off-by: Wei Liu Reviewed-by: Paul Durrant --- v4: 1. Use private.h 2. Add Paul's review tag v2: 1. Fold into setup_pcpu_arg function --- xen/arch/x86/guest/hyperv/hyperv.c | 5 +

Re: [Xen-devel] [RFC PATCH V2 11/11] x86: tsc: avoid system instability in hibernation

On Tue, Jan 14, 2020 at 07:29:52PM +, Anchal Agarwal wrote: > On Tue, Jan 14, 2020 at 12:30:02AM +0100, Rafael J. Wysocki wrote: > > On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki > > wrote: > > > > > > On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra > > > wrote: > > > > > > > > On Mon,

Re: [Xen-devel] HVM Driver Domain

On Wed, Jan 22, 2020 at 07:50:13PM +, tosher 1 wrote: > > > I don't see what is wrong here. Are you sure the backend domain is running? > If you mean the HVM network driver domain then, Yes, I am running the backend > domain. > > > Probably irrelevant at this stage, but do you have

Re: [Xen-devel] HVM Driver Domain

> I don't see what is wrong here. Are you sure the backend domain is running? If you mean the HVM network driver domain then, Yes, I am running the backend domain. > Probably irrelevant at this stage, but do you have "xendriverdomain" service > running in the backend? I do not have this

[Xen-devel] [linux-5.4 test] 146384: regressions - FAIL

flight 146384 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146384/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121

Re: [Xen-devel] libvirt support for scheduler credit2

On 1/21/20 10:05 AM, Jürgen Groß wrote: > On 21.01.20 17:56, Kevin Stange wrote: >> Hi, >> >> I looked around a bit and wasn't able to find a good answer to this, so >> George suggested I ask here. > > Cc-ing Jim. > >> >> Since Xen 4.12, credit2 is the default scheduler, but at least as of >>

Re: [Xen-devel] HVM Driver Domain

On Wed, Jan 22, 2020 at 04:56:15PM +, tosher 1 wrote: > Hi Marek, > > Thanks for your response. The server machine I am using for this setup is an > x86_64 Intel Xeon. For the Dom0, I am using Ubuntu 18.04 running on kernel > version 5.0.0-37-generic. My Xen version is 4.9.2. > > For the

[Xen-devel] [qemu-mainline test] 146388: regressions - FAIL

flight 146388 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146388/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

[Xen-devel] [xen-unstable-smoke test] 146390: tolerable all pass - PUSHED

flight 146390 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146390/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[Xen-devel] [ovmf test] 146385: regressions - FAIL

flight 146385 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146385/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767

Re: [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap

On Wed, Jan 22, 2020 at 8:35 AM Jan Beulich wrote: > > On 21.01.2020 18:49, Tamas K Lengyel wrote: > > When plugging a hole in the target physmap don't use the access permission > > returned by __get_gfn_type_access as it can be non-sensical, > > "can be" is too vague for my taste - it suggests

Re: [Xen-devel] [PATCH v5 11/18] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk

On Wed, Jan 22, 2020 at 8:30 AM Jan Beulich wrote: > > On 21.01.2020 18:49, Tamas K Lengyel wrote: > > @@ -538,24 +535,26 @@ static int audit(void) > > d = get_domain_by_id(g->domain); > > if ( d == NULL ) > > { > > -

Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

On 22.01.2020 17:51, Tamas K Lengyel wrote: > On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote: >> >> On 21.01.2020 18:49, Tamas K Lengyel wrote: >>> The owner domain of shared pages is dom_cow, use that for get_page >>> otherwise the function fails to return the correct page. >> >> I think this

Re: [Xen-devel] HVM Driver Domain

Hi Marek, Thanks for your response. The server machine I am using for this setup is an x86_64 Intel Xeon. For the Dom0, I am using Ubuntu 18.04 running on kernel version 5.0.0-37-generic. My Xen version is 4.9.2. For the HVM driver domain, I am using Ubuntu 18.04 running on kernel version

Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich wrote: > > On 21.01.2020 18:49, Tamas K Lengyel wrote: > > The owner domain of shared pages is dom_cow, use that for get_page > > otherwise the function fails to return the correct page. > > I think this description needs improvement: The function does

Re: [Xen-devel] [PATCH v4 00/16] Add support for qemu-xen runnning in a Linux-based stubdomain.

On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki wrote: > Later patches add QMP over libvchan connection support. The actual connection > is made in a separate process. As discussed on Xen Summit 2019, this allows to > apply some basic checks and/or filtering (not part of this

Re: [Xen-devel] [PATCH v3 2/9] xen: split parameter related definitions in own header file

On 21.01.2020 09:43, Juergen Gross wrote: > Move the parameter related definitions from init.h into a new header > file param.h. This will avoid include hell when new dependencies are > added to parameter definitions. > > Signed-off-by: Juergen Gross x86: Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v5 01/18] x86/hvm: introduce hvm_copy_context_and_params

On Wed, Jan 22, 2020 at 8:01 AM Jan Beulich wrote: > > On 21.01.2020 18:49, Tamas K Lengyel wrote: > > Currently the hvm parameters are only accessible via the HVMOP hypercalls. > > In > > this patch we introduce a new function that can copy both the hvm context > > and > > parameters directly

[Xen-devel] [xen-unstable test] 146379: regressions - FAIL

flight 146379 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146379/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 146058

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

> On 22 Jan 2020, at 14:57, Andrew Cooper wrote: > > On 22/01/2020 01:58, Bobby Eshleman wrote: >> Hey everybody, >> >> This is an RFC patchset for the very beginnings of adding RISC-V support >> to Xen. This RFC is really just to start a dialogue about supporting >> RISC-V and align with

Re: [Xen-devel] [PATCH 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

> -Original Message- > From: Jan Beulich > Sent: 22 January 2020 16:17 > To: Durrant, Paul > Cc: xen-devel@lists.xenproject.org; Jun Nakajima ; > Kevin Tian ; Andrew Cooper > ; Wei Liu ; Roger Pau Monné > ; George Dunlap ; Ian > Jackson ; Julien Grall ; Konrad > Rzeszutek Wilk ; Stefano

Re: [Xen-devel] [PATCH 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

On 21.01.2020 13:00, Paul Durrant wrote: > vmx_alloc_vlapic_mapping() currently contains some very odd looking code > that allocates a MEMF_no_owner domheap page and then shares with the guest > as if it were a xenheap page. This then requires vmx_free_vlapic_mapping() > to call a special function

Re: [Xen-devel] [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() method

> -Original Message- > From: Jan Beulich > Sent: 22 January 2020 16:01 > To: Durrant, Paul > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Wei Liu ; Roger Pau Monné > ; Jun Nakajima ; Kevin Tian > > Subject: Re: [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() > method >

Re: [Xen-devel] [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() method

On 22.01.2020 16:56, Durrant, Paul wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 22 January 2020 15:51 >> To: Durrant, Paul >> Cc: xen-devel@lists.xenproject.org; Andrew Cooper >> ; Wei Liu ; Roger Pau Monné >> ; Jun Nakajima ; Kevin Tian >> >> Subject: Re: [PATCH 2/3] x86

Re: [Xen-devel] [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() method

> -Original Message- > From: Jan Beulich > Sent: 22 January 2020 15:51 > To: Durrant, Paul > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Wei Liu ; Roger Pau Monné > ; Jun Nakajima ; Kevin Tian > > Subject: Re: [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() > method >

Re: [Xen-devel] [PATCH 2/3] x86 / hvm: add domain_relinquish_resources() method

On 21.01.2020 13:00, Paul Durrant wrote: > There are two functions in hvm.c to deal with tear-down and a domain: > hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only > the latter has an associated method in 'hvm_funcs'. This patch adds > a method for the former and stub

Re: [Xen-devel] [PATCH 1/3] x86 / vmx: make apic_access_mfn type-safe

On 22.01.2020 15:05, Andrew Cooper wrote: > On 21/01/2020 12:00, Paul Durrant wrote: >> Use mfn_t rather than unsigned long and change previous tests against 0 to >> tests against INVALID_MFN (also introducing initialization to that value). >> >> Signed-off-by: Paul Durrant > > I'm afraid this

Re: [Xen-devel] [PATCH v2 4/5] x86/boot: Simplify pagetable manipulation loops

On 20/01/2020 10:46, Jan Beulich wrote: > On 17.01.2020 21:42, Andrew Cooper wrote: >> For __page_tables_{start,end} and L3 bootmap initialisation, the logic is >> unnecesserily complicated owing to its attempt to use the LOOP instruction, >> which results in an off-by-8 memory address owing to

Re: [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap

On 21.01.2020 18:49, Tamas K Lengyel wrote: > When plugging a hole in the target physmap don't use the access permission > returned by __get_gfn_type_access as it can be non-sensical, "can be" is too vague for my taste - it suggests there may also be cases where a sensible value is returned, and

Re: [Xen-devel] [PATCH v5 12/18] x86/mem_sharing: Enable mem_sharing on first memop

On 21.01.2020 18:49, Tamas K Lengyel wrote: > It is wasteful to require separate hypercalls to enable sharing on both the > parent and the client domain during VM forking. To speed things up we enable > sharing on the first memop in case it wasn't already enabled. > > Signed-off-by: Tamas K

Re: [Xen-devel] [PATCH v5 11/18] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk

On 21.01.2020 18:49, Tamas K Lengyel wrote: > @@ -538,24 +535,26 @@ static int audit(void) > d = get_domain_by_id(g->domain); > if ( d == NULL ) > { > -MEM_SHARING_DEBUG("Unknown dom: %hu, for PFN=%lx, MFN=%lx\n", > -

Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

On 21.01.2020 18:49, Tamas K Lengyel wrote: > The owner domain of shared pages is dom_cow, use that for get_page > otherwise the function fails to return the correct page. I think this description needs improvement: The function does the special shared page dance in one place (on the "fast path")

Re: [Xen-devel] [PATCH v5 01/18] x86/hvm: introduce hvm_copy_context_and_params

On 21.01.2020 18:49, Tamas K Lengyel wrote: > Currently the hvm parameters are only accessible via the HVMOP hypercalls. In > this patch we introduce a new function that can copy both the hvm context and > parameters directly into a target domain. No functional changes in existing > code. > >

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On 22/01/2020 01:58, Bobby Eshleman wrote: > Hey everybody, > > This is an RFC patchset for the very beginnings of adding RISC-V support > to Xen. This RFC is really just to start a dialogue about supporting > RISC-V and align with the Xen project and community before going > further. For that

Re: [Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API

On Wed, Jan 22, 2020 at 02:44:40PM +, Paul Durrant wrote: > Currently both xl and libxl have internal definitions of INVALID_DOMID > which happen to be identical. However, for the purposes of describing the > behaviour of libxl_domain_create_new/restore() it is useful to have a > specified

[Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate

This patch adds a '-D' command line option to save and migrate to allow the domain id to be incorporated into the saved domain configuration and hence be preserved. Signed-off-by: Paul Durrant --- Cc: Ian Jackson Cc: Wei Liu Cc: Anthony PERARD v2: - Heavily re-worked based on new

[Xen-devel] [PATCH v4 6/7] xl.conf: introduce 'domid_policy'

This patch adds a new global 'domid_policy' configuration option to decide how domain id values are allocated for new domains. It may be set to one of two values: "xen", the default value, will cause an invalid domid value to be passed to do_domain_create() preserving the existing behaviour of

[Xen-devel] [PATCH v4 5/7] libxl: allow creation of domains with a specified or random domid

This patch adds a 'domid' field to libxl_domain_create_info and then modifies libxl__domain_make() to have Xen use that value if it is valid. If the domid value is invalid then Xen will choose the domid, as before, unless the value is the new special RANDOM_DOMID value added to the API. This value

[Xen-devel] [PATCH v4 2/7] libxl_create: make 'soft reset' explicit

The 'soft reset' code path in libxl__domain_make() is currently taken if a valid domid is passed into the function. A subsequent patch will enable higher levels of the toolstack to determine the domid of newly created or restored domains and therefore this criteria for choosing 'soft reset' will

[Xen-devel] [PATCH v4 0/7] xl/libxl: domid allocation/preservation changes

This series was previously named "xl/libxl: allow creation of domains with a specified domid". Paul Durrant (7): libxl: add definition of INVALID_DOMID to the API libxl_create: make 'soft reset' explicit libxl: generalise libxl__domain_userdata_lock() libxl: add infrastructure to track

[Xen-devel] [PATCH v4 4/7] libxl: add infrastructure to track and query 'recent' domids

A domid is considered recent if the domain it represents was destroyed less than a specified number of seconds ago. The number can be set using the environment variable LIBXL_DOMID_REUSE_TIMEOUT. If the variable does not exist then a default value of 60s is used. Whenever a domain is destroyed, a

[Xen-devel] [PATCH v4 1/7] libxl: add definition of INVALID_DOMID to the API

Currently both xl and libxl have internal definitions of INVALID_DOMID which happen to be identical. However, for the purposes of describing the behaviour of libxl_domain_create_new/restore() it is useful to have a specified invalid value for a domain id. This patch therefore moves the libxl

[Xen-devel] [PATCH v4 3/7] libxl: generalise libxl__domain_userdata_lock()

This function implements a file-based lock with a file name generated from a domid. This patch splits it into two, generalising the core of the locking code into a new libxl__lock_file() function which operates on a specified file, leaving just the file name generation in

Re: [Xen-devel] [PATCH v4 08/16] tools/libvchan: notify server when client is connected

On Tue, Jan 21, 2020 at 4:28 PM Marek Marczykowski-Górecki wrote: > > On Mon, Jan 20, 2020 at 02:44:58PM -0500, Jason Andryuk wrote: > > On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki > > wrote: > > > > > > Let the server know when the client is connected. Otherwise server will > > >

[Xen-devel] [PATCH v2] x86/EPT: drop redundant ept_p2m_type_to_flags() parameters

All callers set the respective fields in the entry being updated before the call. Take the opportunity and also constify the first parameter as well as make a few style adjustments. Signed-off-by: Jan Beulich --- v2: Drop redundant function parameters instead. --- a/xen/arch/x86/mm/p2m-ept.c

Re: [Xen-devel] [PATCH v4 07/16] xl: add stubdomain related options to xl config parser

On Tue, Jan 21, 2020 at 4:22 PM Marek Marczykowski-Górecki wrote: > > On Mon, Jan 20, 2020 at 02:41:07PM -0500, Jason Andryuk wrote: > > On Tue, Jan 14, 2020 at 9:40 PM Marek Marczykowski-Górecki > > wrote: > > > > > > Signed-off-by: Marek Marczykowski-Górecki > > > > > > Reviewed-by: Jason

Re: [Xen-devel] [PATCH v4 06/16] libxl: write qemu arguments into separate xenstore keys

On Tue, Jan 21, 2020 at 4:19 PM Marek Marczykowski-Górecki wrote: > > On Mon, Jan 20, 2020 at 02:36:08PM -0500, Jason Andryuk wrote: > > On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki > > wrote: > > > > > > This allows using arguments with spaces, like -append, without > > >

Re: [Xen-devel] [PATCH v4 05/16] libxl: Handle Linux stubdomain specific QEMU options.

On Tue, Jan 21, 2020 at 4:18 PM Marek Marczykowski-Górecki wrote: > > On Mon, Jan 20, 2020 at 02:24:18PM -0500, Jason Andryuk wrote: > > On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki > > wrote: > > > > > > From: Eric Shelton > > > > > > This patch creates an appropriate command

Re: [Xen-devel] [PATCH] xen/x86: domain: Free all the pages associated to struct domain

Hi David, On 22/01/2020 13:50, Woodhouse, David wrote: On Wed, 2020-01-22 at 13:15 +, Andrew Cooper wrote: I'd much rather see the original patch reverted. The current size of struct domain with lockprofile enabled is 3200 bytes. Let me have a look first to see when/why struct domain is

[Xen-devel] [qemu-mainline test] 146387: regressions - FAIL

flight 146387 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-arm64

Re: [Xen-devel] [PATCH v2] x86/hvmloader: round up memory BAR size to 4K

On 22.01.2020 15:04, Jason Andryuk wrote: > On Wed, Jan 22, 2020 at 5:52 AM Roger Pau Monné wrote: >> On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote: >>> On 21.01.2020 17:57, Roger Pau Monné wrote: Ie: Xen should refuse to pass through any memory BAR that's not page

Re: [Xen-devel] [PATCH] tools/save: Drop unused parameters from xc_domain_save()

On 22/01/2020 14:08, Wei Liu wrote: > On Tue, Jan 07, 2020 at 12:19:36PM +, Wei Liu wrote: >> On Mon, Jan 06, 2020 at 05:03:52PM +, Andrew Cooper wrote: >>> XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015), >>> XCFLAGS_HVM since c/s 9e8672f1c (2013), and

Re: [Xen-devel] [PATCH v2] x86/hvmloader: round up memory BAR size to 4K

On 22.01.2020 11:51, Roger Pau Monné wrote: > On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote: >> On 21.01.2020 17:57, Roger Pau Monné wrote: >>> The PCI spec actually recommends memory BARs to be at least of page >>> size, but that's not a strict requirement. I would hope there aren't

Re: [Xen-devel] [PATCH] tools/save: Drop unused parameters from xc_domain_save()

On Tue, Jan 07, 2020 at 12:19:36PM +, Wei Liu wrote: > On Mon, Jan 06, 2020 at 05:03:52PM +, Andrew Cooper wrote: > > XCFLAGS_CHECKPOINT_COMPRESS has been unused since c/s b15bc4345 (2015), > > XCFLAGS_HVM since c/s 9e8672f1c (2013), and XCFLAGS_STDVGA since c/s > > 087d43326 (2007). Drop

Re: [Xen-devel] [PATCH 1/3] x86 / vmx: make apic_access_mfn type-safe

On 21/01/2020 12:00, Paul Durrant wrote: > Use mfn_t rather than unsigned long and change previous tests against 0 to > tests against INVALID_MFN (also introducing initialization to that value). > > Signed-off-by: Paul Durrant I'm afraid this breaks the idempotency of vmx_free_vlapic_mapping(),

Re: [Xen-devel] [PATCH v2 4/4] xen/netback: fix grant copy across page boundary

On Wed, Jan 22, 2020 at 10:07:35AM +, Sergey Dyasli wrote: > On 20/01/2020 08:58, Paul Durrant wrote: > > On Fri, 17 Jan 2020 at 12:59, Sergey Dyasli > > wrote: > >> > >> From: Ross Lagerwall > >> > >> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that > >>

Re: [Xen-devel] [PATCH v4 02/16] Document ioemu Linux stubdomain protocol

On Tue, Jan 21, 2020 at 4:08 PM Marek Marczykowski-Górecki wrote: > > On Mon, Jan 20, 2020 at 01:54:04PM -0500, Jason Andryuk wrote: > > On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki > > wrote: > > > > > > > > > + > > > +Limitations: > > > + - PCI passthrough require permissive

Re: [Xen-devel] [PATCH v2] x86/hvmloader: round up memory BAR size to 4K

On Wed, Jan 22, 2020 at 5:52 AM Roger Pau Monné wrote: > > On Wed, Jan 22, 2020 at 11:27:24AM +0100, Jan Beulich wrote: > > On 21.01.2020 17:57, Roger Pau Monné wrote: > > > On Tue, Jan 21, 2020 at 05:15:20PM +0100, Jan Beulich wrote: > > >> On 21.01.2020 16:57, Roger Pau Monné wrote: > > >>> On

Re: [Xen-devel] [PATCH] xen/x86: domain: Free all the pages associated to struct domain

On Wed, 2020-01-22 at 13:15 +, Andrew Cooper wrote: > > > I'd much rather see the original patch reverted. The current size of > > > struct domain with lockprofile enabled is 3200 bytes. > > > > Let me have a look first to see when/why struct domain is less than 4K > > with lockprofile. > >

Re: [Xen-devel] [PATCH] xen/x86: domain: Free all the pages associated to struct domain

On 22/01/2020 13:13, Julien Grall wrote: > Hi Andrew, > > On 22/01/2020 12:52, Andrew Cooper wrote: >> On 20/01/2020 14:31, Julien Grall wrote: >>> From: Julien Grall >>> >>> The structure domain may be bigger than a page size when lock profiling >>> is enabled. However, the function

Re: [Xen-devel] [PATCH] xen/x86: domain: Free all the pages associated to struct domain

Hi Andrew, On 22/01/2020 12:52, Andrew Cooper wrote: On 20/01/2020 14:31, Julien Grall wrote: From: Julien Grall The structure domain may be bigger than a page size when lock profiling is enabled. However, the function free_domheap_struct will only free the first page. This is not a

Re: [Xen-devel] [PATCH v2 0/9] xen: scheduler cleanups

On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote: > Move all scheduler related hypervisor code to xen/common/sched/ and > do a lot of cleanups. > > Juergen Gross (9): > xen/sched: move schedulers and cpupool coding to dedicated > directory > xen/sched: make sched-if.h really scheduler

Re: [Xen-devel] [PATCH v2 4/9] xen/sched: remove special cases for free cpus in schedulers

On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote: > With the idle scheduler now taking care of all cpus not in any > cpupool > the special cases in the other schedulers for no cpupool associated > can be removed. > > Signed-off-by: Juergen Gross > Reviewed-by: Dario Faggioli Regards --

Re: [Xen-devel] [PATCH v2 6/9] xen/sched: replace null scheduler percpu-variable with pdata hook

On Wed, 2020-01-08 at 16:23 +0100, Juergen Gross wrote: > Instead of having an own percpu-variable for private data per cpu the > generic scheduler interface for that purpose should be used. > > Signed-off-by: Juergen Gross > Reviewed-by: Dario Faggioli Regards -- Dario Faggioli, Ph.D

  1   2   >