Re: [Xen-devel] [PATCH] Arm/p2m: fix build after ea22bcd030da and 2aa977eb6baa

On 1/24/20 8:51 AM, Jan Beulich wrote: > Each of these commits introduced a function prototype referencing a > structure which hadn't at least been forward declared. Add such > declarations. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap I wouldn't object if you decided to check these

[Xen-devel] [xen-unstable-smoke test] 146462: regressions - FAIL

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

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

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

[Xen-devel] [PATCH] Arm/p2m: fix build after ea22bcd030da and 2aa977eb6baa

Each of these commits introduced a function prototype referencing a structure which hadn't at least been forward declared. Add such declarations. Signed-off-by: Jan Beulich --- a/xen/include/xen/mem_access.h +++ b/xen/include/xen/mem_access.h @@ -58,6 +58,7 @@ typedef enum { /* NOTE:

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

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: 23 January 2020 14:46 > To: Durrant, Paul ; xen-devel@lists.xenproject.org > Cc: Jan Beulich ; Andrew Cooper > ; Wei Liu ; Roger Pau Monné > ; George Dunlap ; Ian > Jackson ; Julien Grall ; Konrad >

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

flight 146445 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146445/ 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] Arm/p2m: fix build after ea22bcd030da and 2aa977eb6baa

On 24.01.2020 11:05, George Dunlap wrote: > On 1/24/20 8:51 AM, Jan Beulich wrote: >> Each of these commits introduced a function prototype referencing a >> structure which hadn't at least been forward declared. Add such >> declarations. >> >> Signed-off-by: Jan Beulich > > Acked-by: George

Re: [Xen-devel] HVM Driver Domain

On Thu, Jan 23, 2020 at 10:36:34PM +, tosher 1 wrote: > > > I wasn't able to make the HVM driver domain work even with the latest Xen > version which is 4.14. I see the 'xendriverdomain' executable in the > /etc/init.d/ directory, but it doesn't seem to be running in the background. The

Re: [Xen-devel] [PATCH] x86/mem_access: move _ve functions to x86 header

On 24/01/2020 13:56, Tamas K Lengyel wrote: > These functions don't belong in the common mem_access header as there is no > #VE > equivalent on ARM. > > Signed-off-by: Tamas K Lengyel Thanks for the patch, but Jan has already committed the more simple build fix.  Can you rebase this on staging?

Re: [Xen-devel] [PATCH] x86/mem_access: move _ve functions to x86 header

On 24.01.2020 14:56, Tamas K Lengyel wrote: > These functions don't belong in the common mem_access header as there is no > #VE > equivalent on ARM. > > Signed-off-by: Tamas K Lengyel Acked-by: Jan Beulich ___ Xen-devel mailing list

[Xen-devel] [PATCH] x86/mem_access: move _ve functions to x86 header

These functions don't belong in the common mem_access header as there is no #VE equivalent on ARM. Signed-off-by: Tamas K Lengyel --- xen/include/asm-x86/mem_access.h | 10 ++ xen/include/xen/mem_access.h | 10 -- 2 files changed, 10 insertions(+), 10 deletions(-) diff

[Xen-devel] [xen-unstable-smoke test] 146472: regressions - FAIL

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

Re: [Xen-devel] [RFC 0/6] vDSO support for Hyper-V guest on ARM64

Hi Boqun Feng, On 24/01/2020 06:32, Boqun Feng wrote: > Hi Vincenzo, > [...] >> >> I had a look to your patches and overall, I could not understand why we can't >> use the arch_timer to do the same things you are doing with the one you >> introduced in this series. What confuses me is that KVM

Re: [Xen-devel] [PATCH] x86/mem_access: move _ve functions to x86 header

On 24/01/2020 13:59, Tamas K Lengyel wrote: > On Fri, Jan 24, 2020 at 6:57 AM Andrew Cooper > wrote: >> On 24/01/2020 13:56, Tamas K Lengyel wrote: >>> These functions don't belong in the common mem_access header as there is no >>> #VE >>> equivalent on ARM. >>> >>> Signed-off-by: Tamas K

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

flight 146468 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146468/ 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 v4 12/16] libxl: use vchan for QMP access with Linux stubdomain

On Tue, Jan 21, 2020 at 6:46 PM Marek Marczykowski-Górecki wrote: > > > +static void spawn_qmp_proxy(libxl__egc *egc, > > > +libxl__stub_dm_spawn_state *sdss) > > > +{ > > > +STATE_AO_GC(sdss->qmp_proxy_spawn.ao); > > > +const uint32_t guest_domid =

Re: [Xen-devel] HVM Driver Domain

On Wed, Jan 22, 2020 at 2:03 PM Marek Marczykowski-Górecki wrote: > > 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

[Xen-devel] [xen-unstable-smoke test] 146469: regressions - FAIL

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

Re: [Xen-devel] [PATCH] x86/mem_access: move _ve functions to x86 header

On Fri, Jan 24, 2020 at 6:57 AM Andrew Cooper wrote: > > On 24/01/2020 13:56, Tamas K Lengyel wrote: > > These functions don't belong in the common mem_access header as there is no > > #VE > > equivalent on ARM. > > > > Signed-off-by: Tamas K Lengyel > > Thanks for the patch, but Jan has

Re: [Xen-devel] [PATCH] Arm/p2m: fix build after ea22bcd030da and 2aa977eb6baa

On Fri, Jan 24, 2020 at 5:50 AM Jan Beulich wrote: > > On 24.01.2020 11:05, George Dunlap wrote: > > On 1/24/20 8:51 AM, Jan Beulich wrote: > >> Each of these commits introduced a function prototype referencing a > >> structure which hadn't at least been forward declared. Add such > >>

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

flight 146465 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146465/ 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] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On 22/01/2020 01:58, Bobby Eshleman wrote: > Currently, this patchset really only sets up virtual memory for Xen and > initializes UART to enable print output. None of RISC-V's > virtualization support has been implemented yet, although that is the > next road to start going down. Many functions

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

flight 146473 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146473/ 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] 146477: tolerable all pass - PUSHED

flight 146477 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146477/ 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] mm: remove donate_page()

Sent from Workspace ONE Boxer On 24 Jan 2020 17:57, Andrew Cooper wrote: > > On 24/01/2020 15:31, Paul Durrant wrote: > > This function appears to have no callers. > > > > Signed-off-by: Paul Durrant > > Looks like tmem was the sole user. donate_page() was introduced by > 6009f4ddb2 and the

Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

Sorry for the late reply on this one. > +func NewDomainConfig(t DomainType) (*DomainConfig, error) { > + var cconfig C.libxl_domain_config > + > + C.libxl_domain_config_init() > + C.libxl_domain_build_info_init_type(_info, > C.libxl_domain_type(t)) > + > + gconfig := {} >

Re: [Xen-devel] HVM Driver Domain

> > builder = "hvm" > > name = "ubuntu-doment-hvm" > This name... > > vif = [ 'backend=ubuntu-domnet-hvm,bridge=xenbr1' ] > ...and this name don't match. Jason, Thanks for pointing this out. I feel very stupid. However, the problem is not solved yet, but I was able to get to the next step

Re: [Xen-devel] [PATCH v3 5/8] golang/xenlight: Default loglevel to DEBUG until we get everything working

> But really, we need a way to actually create a logger properly. Apparently > one thing libvirt does is to create a logger to a file for each guest. > That’s something our package users might want to do at some point. Yes, I think package users will want logging to be pretty flexible. I

Re: [Xen-devel] [PATCH v4 12/16] libxl: use vchan for QMP access with Linux stubdomain

On Fri, Jan 24, 2020 at 02:58:56PM -0500, Rich Persaud wrote: > On Jan 24, 2020, at 09:07, Jason Andryuk wrote: > > > > On Tue, Jan 21, 2020 at 6:46 PM Marek Marczykowski-Górecki > > wrote: > > > + > +sdss->qmp_proxy_spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT > *

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

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

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

flight 146476 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146476/ 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 v4 12/16] libxl: use vchan for QMP access with Linux stubdomain

On Jan 24, 2020, at 09:07, Jason Andryuk wrote: > > On Tue, Jan 21, 2020 at 6:46 PM Marek Marczykowski-Górecki > wrote: > + +sdss->qmp_proxy_spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000; +sdss->qmp_proxy_spawn.midproc_cb = libxl__spawn_record_pid;

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

flight 146480 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146480/ 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 1/2] xen/arm: remove physical timer offset

On 1/23/2020 7:32 AM, Julien Grall wrote: > Hi, > > On 21/01/2020 15:07, Jeff Kubascik wrote: >> The physical timer traps apply an offset so that time starts at 0 for >> the guest. However, this offset is not currently applied to the physical >> counter. Per the ARMv8 Reference Manual (ARM DDI

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: remove physical timer offset

On 24/01/2020 21:43, Jeff Kubascik wrote: On 1/23/2020 7:32 AM, Julien Grall wrote: Hi, On 21/01/2020 15:07, Jeff Kubascik wrote: The physical timer traps apply an offset so that time starts at 0 for the guest. However, this offset is not currently applied to the physical counter. Per the

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

flight 146481 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146481/ 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 7/7] mm: remove donate_page()

On 1/24/20 3:31 PM, Paul Durrant wrote: > This function appears to have no callers. > > Signed-off-by: Paul Durrant Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v4 7/7] mm: remove donate_page()

Hi Paul, On 24/01/2020 15:31, Paul Durrant wrote: This function appears to have no callers. Signed-off-by: Paul Durrant Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

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

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

[Xen-devel] [PATCH v4 7/7] mm: remove donate_page()

This function appears to have no callers. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Julien Grall Cc: Volodymyr Babchuk Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Wei Liu Cc: "Roger Pau Monné" v4: - New in v4 ---

[Xen-devel] [PATCH v4 6/7] x86 / vmx: use a MEMF_no_refcount domheap page for APIC_DEFAULT_PHYS_BASE

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 in the mm code: free_shared_domheap_page(). By

[Xen-devel] [PATCH v4 3/7] x86 / hvm: make domain_destroy() method optional

This method is currently empty for SVM so make it optional and, while in the neighbourhood, make it an alternative_vcall(). Signed-off-by: Paul Durrant --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: "Roger Pau Monné" Cc: George Dunlap v4: - New in v4 (disaggregated from v3 patch

[Xen-devel] [PATCH v4 5/7] mm: make MEMF_no_refcount pages safe to assign

Currently it is unsafe to assign a domheap page allocated with MEMF_no_refcount to a domain because the domain't 'tot_pages' will not be incremented, but will be decrement when the page is freed (since free_domheap_pages() has no way of telling that the increment was skipped). This patch

[Xen-devel] [PATCH v4 0/7] purge free_shared_domheap_page()

The last patch is unrelated cleanup for something I happened to notice along the way. Paul Durrant (7): x86 / vmx: make apic_access_mfn type-safe x86 / hvm: add domain_relinquish_resources() method x86 / hvm: make domain_destroy() method optional x86 / vmx: move teardown from

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

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. A subsequent patch will define a VMX implementation.

[Xen-devel] [PATCH v4 4/7] x86 / vmx: move teardown from domain_destroy()...

... to domain_relinquish_resources(). The teardown code frees the APICv page. This does not need to be done late so do it in domain_relinquish_resources() rather than domain_destroy(). Signed-off-by: Paul Durrant --- Cc: Jun Nakajima Cc: Kevin Tian Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei

[Xen-devel] [PATCH v4 1/7] x86 / vmx: make apic_access_mfn type-safe

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 Acked-by: Kevin Tian Reviewed-by: Jan Beulich --- Cc: Andrew Cooper Cc: Wei Liu Cc: "Roger Pau Monné" Cc: Jun

Re: [Xen-devel] [PATCH v4 7/7] mm: remove donate_page()

On 24/01/2020 15:31, Paul Durrant wrote: > This function appears to have no callers. > > Signed-off-by: Paul Durrant Looks like tmem was the sole user.  donate_page() was introduced by 6009f4ddb2 and the last caller was dropped by c492e19fdd. This patch is standalone, and I can tweak the commit

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

flight 146475 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146475/ 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 3/7] x86 / hvm: make domain_destroy() method optional

On 24.01.2020 16:30, Paul Durrant wrote: > This method is currently empty for SVM so make it optional and, while in > the neighbourhood, make it an alternative_vcall(). > > Signed-off-by: Paul Durrant Acked-by: Jan Beulich ___ Xen-devel mailing list

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

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

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

[Xen-devel] [xen-unstable test] 146484: tolerable FAIL - PUSHED

flight 146484 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146484/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 146058 Tests which did not

Re: [Xen-devel] [XEN PATCH 2/3] automation: updating container to have python3-config binary

On 1/20/20 5:50 AM, Anthony PERARD wrote: Those containers have already been updated in GitLab: - debian/stretch - debian/stretch-i386 - debian/unstable - debian/unstable-i386 - fedora/29 - suse/opensuse-leap - ubuntu/bionic - ubuntu/trusty - ubuntu/xenial The container

Re: [Xen-devel] [XEN PATCH 1/3] automation: Only build QEMU if Python >= 3.5

On 1/20/20 5:50 AM, Anthony PERARD wrote: Recent version of QEMU will not build anymore if Python < 3.5. That is, QEMU 4.3 not released yet. That check would also prevent the GitLab CI from building QEMU if python3 binary isn't present. Signed-off-by: Anthony PERARD Acked-by: Doug

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

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

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

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

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

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

flight 146485 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146485/ 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] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

On Thu, Jan 23, 2020 at 04:02:56PM +, Andrew Cooper wrote: > > We have https://gitlab.com/xen-project/xen/pipelines which runs a load > of containerised builds.  How easy is it to set up a containerised > RISC-V cross-compiler environment? > It's pretty easy. I personally use a Docker

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

On Thu, Jan 23, 2020 at 11:44:02PM +, Lars Kurth wrote: > If you add your name/email address to > https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ > I will CC > you on the next invite > They are usually the 1st

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

On Fri, Jan 24, 2020 at 01:41:38PM +, Andrew Cooper wrote: > On 22/01/2020 01:58, Bobby Eshleman wrote: > > Currently, this patchset really only sets up virtual memory for Xen and > > initializes UART to enable print output. None of RISC-V's > > virtualization support has been implemented