[ovmf test] 149292: all pass - PUSHED

flight 149292 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149292/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e210fc130e5c9738909dca432bbf8bf277ba6e37 baseline version: ovmf

[linux-5.4 test] 149270: regressions - FAIL

flight 149270 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/149270/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121 Tests which

[linux-linus test] 149266: regressions - FAIL

flight 149266 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/149266/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 149238 build-arm64-pvops

Re: [PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string

Hi Ian, On 31/03/2020 12:17, Ian Jackson wrote: Julien Grall writes ("[PATCH 0/8] Fix build with using OCaml 4.06.1 and -safe-string"): This series is meant to solve the build issue reported by Dario when using recent version of OCaml and -safe-string. Thanks. I have reviewed the C tools

[qemu-mainline test] 149264: regressions - FAIL

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

Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

On Wed, 1 Apr 2020, Andrei Cherechesu wrote: > > I cannot see any issues with the driver. Can you paste the device tree as > > dom0 > > sees it? You can access it from /proc/device-tree (you can convert it to dts > > with dtc -I fs -O dts). And also the host device tree? > > > > We should see

Re: [PATCH] guestcopy: evaluate {,__}copy{,_field}_to_guest*() arguments just once

Hi, On 01/04/2020 15:29, Jan Beulich wrote: There's nothing wrong with having e.g. copy_to_guest(uarg, ptr++, 1); yet until now this would increment "ptr" twice. Is there such use in Xen today? I guess not as we would have noticed any issue. Also drop a pair of unneeded parentheses

Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to prevent const dest operand

Hi Jan, On 01/04/2020 10:25, Jan Beulich wrote: On 31.03.2020 21:13, Julien Grall wrote: I am not aware of any way before C11 to check if a variable is const or not. If we wanted to keep allow void type the handle then a possible approach would be: #define copy_to_guest_offset(hnd, off, ptr,

Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

Hi, On 01/04/2020 20:58, Andrei Cherechesu wrote: I cannot see any issues with the driver. Can you paste the device tree as dom0 sees it? You can access it from /proc/device-tree (you can convert it to dts with dtc -I fs -O dts). And also the host device tree? We should see something like the

[xen-unstable-smoke test] 149296: tolerable all pass - PUSHED

flight 149296 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/149296/ 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] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

> I cannot see any issues with the driver. Can you paste the device tree as dom0 > sees it? You can access it from /proc/device-tree (you can convert it to dts > with dtc -I fs -O dts). And also the host device tree? > > We should see something like the following (this example is taken from a >

[xen-unstable test] 149260: regressions - FAIL

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

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On 01/04/2020 18:02, George Dunlap wrote: On Wed, Apr 1, 2020 at 10:54 AM Bertrand Marquis mailto:bertrand.marq...@arm.com>> wrote: On 1 Apr 2020, at 09:30, Julien Grall mailto:jul...@xen.org>> wrote: On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020,

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On 01/04/2020 10:54, Bertrand Marquis wrote: On 1 Apr 2020, at 09:30, Julien Grall > wrote: On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020, Julien Grall wrote: Hi Stefano, On 30/03/2020 17:35, Stefano Stabellini wrote: On Sat, 28 Mar 2020,

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On Wed, Apr 1, 2020 at 10:54 AM Bertrand Marquis wrote: > > > On 1 Apr 2020, at 09:30, Julien Grall wrote: > > > > On 01/04/2020 01:57, Stefano Stabellini wrote: > > On Mon, 30 Mar 2020, Julien Grall wrote: > > Hi Stefano, > > On 30/03/2020 17:35, Stefano Stabellini wrote: > > On Sat, 28 Mar

Re: [PATCH] timeout: adjust timeout when running nested tests

Roger Pau Monne writes ("Re: [PATCH] timeout: adjust timeout when running nested tests"): > On Wed, Apr 01, 2020 at 05:45:21PM +0100, Ian Jackson wrote: > > I think this wannts to be // not ||. If you agree I will fix this up > > and commit. > > Yes, I agree. Thanks, done and pushed. > >

Re: [PATCH] timeout: adjust timeout when running nested tests

On Wed, Apr 01, 2020 at 05:45:21PM +0100, Ian Jackson wrote: > Roger Pau Monne writes ("[PATCH] timeout: adjust timeout when running nested > tests"): > > sub target_adjust_timeout ($$) { > > my ($ho,$timeoutref) = @_; # $ho might be a $gho > > +my $nestinglvl = $ho->{NestingLevel} ||

Re: [PATCH] timeout: adjust timeout when running nested tests

Roger Pau Monne writes ("[PATCH] timeout: adjust timeout when running nested tests"): > sub target_adjust_timeout ($$) { > my ($ho,$timeoutref) = @_; # $ho might be a $gho > +my $nestinglvl = $ho->{NestingLevel} || $ho->{Host}{NestingLevel}; I think this wannts to be // not ||. If you

Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

On Wed, 1 Apr 2020, Andrei Cherechesu wrote: > Hi, > > And thanks for your help. > > > Great to hear! > > > > > > > However, I am encountering another problem now: in Dom0 and in > > > dom0less-booted DomUs, I cannot use /dev/hvc0. > > > > For dom0less-booted DomUs it is normal because they

Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for XenDevice-s

Hi Anthony, Paul. Cc'ing Markus too. On 1/14/19 2:51 PM, Anthony PERARD wrote: From: Paul Durrant This patch adds a new source module, xen-bus-helper.c, which builds on basic libxenstore primitives to provide functions to create (setting permissions appropriately) and destroy xenstore areas,

[xen-unstable-smoke test] 149284: tolerable all pass - PUSHED

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

Make VM save/restore and VM migration work on ARM.

Hello! Just wonder if this Open Work Item is still available? https://wiki.xenproject.org/wiki/Xen_ARM_TODO Thank you, Asaf Fisher

[ovmf test] 149262: all pass - PUSHED

flight 149262 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149262/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4 baseline version: ovmf

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

On 27.03.2020 19:50, Paul Durrant wrote: > Domain context is state held in the hypervisor that does not come under > the category of 'HVM state' but is instead 'PV state' that is common > between PV guests and enlightened HVM guests (i.e. those that have PV > drivers) such as event channel state,

[libvirt test] 149268: regressions - FAIL

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

[PATCH] guestcopy: evaluate {, __}copy{, _field}_to_guest*() arguments just once

There's nothing wrong with having e.g. copy_to_guest(uarg, ptr++, 1); yet until now this would increment "ptr" twice. Also drop a pair of unneeded parentheses from every instance at this occasion. Fixes: b7954cc59831 ("Enhance guest memory accessor macros so that source operands can be")

Re: [PATCH 4/5] common/domain: add a domain context record for shared_info...

HI Paul, On 27/03/2020 18:50, Paul Durrant wrote: ... and update xen-ctx to dump some information describing the record. The commit message should contain a little bit more context why we are saving/restore the shared_info. NOTE: To allow a sensible definition of the record in

Re: [PATCH 2/5] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext

On 27/03/2020 18:50, Paul Durrant wrote: + * XEN_DOMCTL_getdomaincontext + * --- + * + * buffer (IN): The buffer into which the context data should be + *copied, or NULL to query the buffer size that should + *be allocated. + * size

Re: [PATCH 2/5] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext

Hi Paul, On 27/03/2020 18:50, Paul Durrant wrote: These domctls provide a mechanism to get and set domain context from the toolstack. Signed-off-by: Paul Durrant --- Cc: Daniel De Graaf Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Jan Beulich Cc: Julien Grall Cc:

[PATCH] timeout: adjust timeout when running nested tests

Expand the timeouts when the host is nested. The current algorithm uses base_timeout * 2 ^ nesting_level. This fixes the issues reported by the nested tests on elbling boxes: http://logs.test-lab.xenproject.org/osstest/logs/149283/ Signed-off-by: Roger Pau Monné --- Osstest/TestSupport.pm | 4

[xen-unstable-smoke test] 149278: tolerable all pass - PUSHED

flight 149278 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/149278/ 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: [PATCH 5/5] x86_64/mm: map and unmap page tables in destroy_m2p_mapping

On 23.03.2020 10:41, Hongyan Xia wrote: > @@ -297,26 +298,33 @@ static void destroy_m2p_mapping(struct mem_hotadd_info > *info) > continue; > } > > -l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]); > +l2_ro_mpt =

Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in share_hotadd_m2p_table

On 23.03.2020 10:41, Hongyan Xia wrote: > --- a/xen/include/asm-x86/page.h > +++ b/xen/include/asm-x86/page.h > @@ -196,6 +196,24 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa, > unsigned int flags) > #define map_l2t_from_l3e(x)(l2_pgentry_t > *)map_domain_page(l3e_get_mfn(x))

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

On 01.04.2020 14:16, Julien Grall wrote: > Hi Jan, > > On 01/04/2020 13:07, Jan Beulich wrote: >> On 01.04.2020 14:00, Julien Grall wrote: >>> On 27/03/2020 18:50, Paul Durrant wrote: +    if ( (exact ? +  (dst_len != c->desc.length) : (dst_len < c->desc.length)) || >>> >>>

Re: [PATCH 2/5] x86_64/mm: map and unmap page tables in m2p_mapped

On 23.03.2020 10:41, Hongyan Xia wrote: > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -131,27 +131,33 @@ static int m2p_mapped(unsigned long spfn) > unsigned long va; > l3_pgentry_t *l3_ro_mpt; > l2_pgentry_t *l2_ro_mpt; > +int rc = M2P_NO_MAPPED; > >

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

Hi Jan, On 01/04/2020 13:07, Jan Beulich wrote: On 01.04.2020 14:00, Julien Grall wrote: On 27/03/2020 18:50, Paul Durrant wrote: +    if ( (exact ? +  (dst_len != c->desc.length) : (dst_len < c->desc.length)) || Using ternary in if is really confusing. How about: dst_len <

Re: [PATCH 1/5] x86/shim: map and unmap page tables in replace_va_mapping

On 23.03.2020 10:41, Hongyan Xia wrote: > --- a/xen/arch/x86/pv/shim.c > +++ b/xen/arch/x86/pv/shim.c > @@ -169,15 +169,19 @@ static void __init replace_va_mapping(struct domain *d, > l4_pgentry_t *l4start, >unsigned long va, mfn_t mfn) > { >

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

On 01.04.2020 14:00, Julien Grall wrote: > On 27/03/2020 18:50, Paul Durrant wrote: >> +    if ( (exact ? >> +  (dst_len != c->desc.length) : (dst_len < c->desc.length)) || > > Using ternary in if is really confusing. How about: > > dst_len < c->desc.length || (exact && dst_len !=

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

Hi Paul, On 27/03/2020 18:50, Paul Durrant wrote: Domain context is state held in the hypervisor that does not come under the category of 'HVM state' but is instead 'PV state' that is common between PV guests and enlightened HVM guests (i.e. those that have PV drivers) such as event channel

[PATCH 5/5] x86/p2m: use available local variable in guest_physmap_add_entry()

The domain is being passed in - no need to obtain it from p2m->domain. Also drop a pointless cast while touching this code anyway. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -905,7 +905,7 @@ guest_physmap_add_entry(struct domain *d if (

[PATCH 4/5] x86/p2m: drop pointless nested variable from guest_physmap_add_entry()

There's an outer scope rc already, and its use for the mem-sharing logic does not conflict with its use elsewhere in the function. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -905,7 +905,6 @@ guest_physmap_add_entry(struct domain *d if (

[PATCH 2/5] x86/p2m: don't assert that the passed in MFN matches for a remove

guest_physmap_remove_page() gets handed an MFN from the outside, yet takes the necessary lock to prevent further changes to the GFN <-> MFN mapping itself. While some callers, in particular guest_remove_page() (by way of having called get_gfn_query()), hold the GFN lock already, various others

[PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe

Also add a couple of blank lines. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -768,11 +768,10 @@ void p2m_final_teardown(struct domain *d } static int __must_check -p2m_remove_page(struct p2m_domain *p2m, unsigned long gfn_l, unsigned long mfn,

[PATCH 1/5] x86/p2m: don't ignore p2m_remove_page()'s return value

It's not very nice to return from guest_physmap_add_entry() after perhaps already having made some changes to the P2M, but this is pre- existing practice in the function, and imo better than ignoring errors. Take the liberty and replace an mfn_add() instance with a local variable already holding

[PATCH 0/5] x86/p2m: misc page add/remove adjustments

The primary change here is patch 2, with the others being cleanup noticed to be worthwhile along the road. 1: don't ignore p2m_remove_page()'s return value 2: don't assert that the passed in MFN matches for a remove 3: make p2m_remove_page()'s parameters type-safe 4: drop pointless nested

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

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

Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

Hi, And thanks for your help. > Great to hear! > > > > However, I am encountering another problem now: in Dom0 and in > > dom0less-booted DomUs, I cannot use /dev/hvc0. > > For dom0less-booted DomUs it is normal because they don't get a PV console, > they get an emulated PL011 UART instead.

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On 1 Apr 2020, at 09:30, Julien Grall mailto:jul...@xen.org>> wrote: On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020, Julien Grall wrote: Hi Stefano, On 30/03/2020 17:35, Stefano Stabellini wrote: On Sat, 28 Mar 2020, Julien Grall wrote: qHi Stefano, On 27/03/2020 02:34,

Re: [PATCH 2/8] xen/public: sysctl: set_parameter.params and debug.keys should be const

Hi Jan, On 31/03/2020 08:30, Jan Beulich wrote: On 30.03.2020 21:21, Julien Grall wrote: From: Julien Grall The fields set_parameter.params and debug.keys should never be modified by the hypervisor. So mark them as const. Signed-off-by: Julien Grall Reviewed-by: Jan Beulich I am not

Re: [XEN PATCH v4 00/18] xen: Build system improvements

Hi Anthony, On 31/03/2020 11:30, Anthony PERARD wrote: Anthony PERARD (18): xen/arm: Rename all early printk macro xen/arm: Configure early printk via Kconfig build,arm: Fix deps check of head.o I have merged the first 3 patches. Cheers, -- Julien Grall

Re: [XEN PATCH v4 03/18] build,arm: Fix deps check of head.o

Hi Anthony, On 31/03/2020 11:30, Anthony PERARD wrote: arm*/head.o isn't in obj-y or extra-y, so make don't load the associated .*.d file (or .*.cmd file when if_changed will be used). There is a workaround where .*.d file is added manually into DEPS. Changing DEPS isn't needed, we can simply

Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to prevent const dest operand

On 31.03.2020 21:13, Julien Grall wrote: > I am not aware of any way before C11 to check if a variable is > const or not. If we wanted to keep allow void type the handle > then a possible approach would be: > > #define copy_to_guest_offset(hnd, off, ptr, nr) ({  \ >     const

Re: [XEN PATCH v4 02/18] xen/arm: Configure early printk via Kconfig

Hi Anthony, On 31/03/2020 11:30, Anthony PERARD wrote: At the moment, early printk can only be configured on the make command line. It is not very handy because a user has to remove the option everytime it is using another command other than compiling the hypervisor. Furthermore, early printk

Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to prevent const dest operand

Hi Jan, On 01/04/2020 07:48, Jan Beulich wrote: On 31.03.2020 21:13, Julien Grall wrote: On 31/03/2020 08:26, Jan Beulich wrote: On 30.03.2020 21:21, Julien Grall wrote: From: Julien Grall At the moment, copy_to_guest_offset() will allow the hypervisor to copy data to guest handle marked

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020, Julien Grall wrote: Hi Stefano, On 30/03/2020 17:35, Stefano Stabellini wrote: On Sat, 28 Mar 2020, Julien Grall wrote: qHi Stefano, On 27/03/2020 02:34, Stefano Stabellini wrote: This is a simple implementation of

Re: [PATCH] x86/dom0: fix copy of low 1MB data for PVH

On 31.03.2020 18:33, Roger Pau Monne wrote: > The orders of start and end are inverted in order to calculate the > size of the copy operation. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag

On 01.04.2020 09:15, Roger Pau Monné wrote: > On Wed, Apr 01, 2020 at 08:34:23AM +0200, Jan Beulich wrote: >> On 31.03.2020 18:45, Roger Pau Monné wrote: >>> On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote: On 20.03.2020 19:42, Roger Pau Monne wrote: > @@ -993,7 +993,7 @@

Re: [linux-5.4 test] 149244: regressions - FAIL

On Wed, Apr 01, 2020 at 06:45:56AM +, osstest service owner wrote: > flight 149244 linux-5.4 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/149244/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag

On Wed, Apr 01, 2020 at 08:34:23AM +0200, Jan Beulich wrote: > On 31.03.2020 18:45, Roger Pau Monné wrote: > > On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote: > >> On 20.03.2020 19:42, Roger Pau Monne wrote: > >>> --- a/xen/arch/x86/mm/hap/hap.c > >>> +++ b/xen/arch/x86/mm/hap/hap.c >

Re: [PATCH 1/8] xen/guest_access: Harden copy_to_guest_offset to prevent const dest operand

On 31.03.2020 21:13, Julien Grall wrote: > On 31/03/2020 08:26, Jan Beulich wrote: >> On 30.03.2020 21:21, Julien Grall wrote: >>> From: Julien Grall >>> >>> At the moment, copy_to_guest_offset() will allow the hypervisor to copy >>> data to guest handle marked const. >>> >>> Thankfully, no users

[linux-5.4 test] 149244: regressions - FAIL

flight 149244 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/149244/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121 Tests which

Re: [PATCH v8 1/3] x86/tlb: introduce a flush HVM ASIDs flag

On 31.03.2020 18:45, Roger Pau Monné wrote: > On Tue, Mar 31, 2020 at 05:40:59PM +0200, Jan Beulich wrote: >> On 20.03.2020 19:42, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/mm/hap/hap.c >>> +++ b/xen/arch/x86/mm/hap/hap.c >>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d, >>>