[PATCH v1] tools: handle more than 16T in precopy_stats

total_written tracks the number of transferred dirty pages. Signed-off-by: Olaf Hering --- tools/include/xenguest.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h index a9984dbea5..775cf34c04 100644 --- a/tools/include/xeng

Re: [PATCH 1/2] x86/mem_sharing: copy cpuid during vm forking

On 04.01.2021 18:41, Tamas K Lengyel wrote: > --- a/xen/arch/x86/mm/mem_sharing.c > +++ b/xen/arch/x86/mm/mem_sharing.c > @@ -1764,6 +1764,7 @@ static int fork(struct domain *cd, struct domain *d) > > domain_pause(d); > cd->max_pages = d->max_pages; > +memcpy(cd->arch.cp

Re: [PATCH 2/6] x86/mm: p2m_add_foreign() is HVM-only

On 04.01.2021 17:57, Oleksandr Tyshchenko wrote: > Hello all. > > [Sorry for the possible format issues] > > On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper > wrote: > >> On 21/12/2020 08:10, Jan Beulich wrote: >>> On 17.12.2020 20:18, Andrew Cooper wrote: On 15/12/2020 16:26, Jan Beulich w

[PATCH] xen/arm: Using unsigned long for arm64 MPIDR mask

Curretly, Xen is using UINT32 for MPIDR mask to retrieve affinity[0,1,2,3] values for MPIDR_EL1 register. The value of MPIDR_EL1 is 64-bit unsigned long. The operation of 64-bit and 32-bit integers are compiler related. This means the value is unpredictable. For example, when we are using MPIDR_AF

[PATCH 0/2] libs: implement some missing functions on FreeBSD

Add support for dm_op, restrict and map resource ioctls on FreeBSD. Roger Pau Monne (2): libs/foreignmemory: implement the missing functions on FreeBSD libs/devicemodel: add dm_op support for FreeBSD tools/include/xen-sys/FreeBSD/privcmd.h | 29 +++ tools/libs/devicemodel/Makefi

[PATCH 1/2] libs/foreignmemory: implement the missing functions on FreeBSD

Implement restrict, map resource and unmap resource helpers on FreeBSD. Signed-off-by: Roger Pau Monné --- Note the implementation is fairly similar to the Linux one, so could likely be merged with some ifdefary. Note sure it's worth it given that we already have a split file. --- tools/include/

[PATCH 2/2] libs/devicemodel: add dm_op support for FreeBSD

The FreeBSD ioctls have the same fields has the Linux ones, so the same file can be shared between both OSes. No functional change for OSes different than FreeBSD. Signed-off-by: Roger Pau Monné --- tools/include/xen-sys/FreeBSD/privcmd.h | 15 +++ tools/libs/devicemodel/Makefi

Re: Identify an specific DomU inpecting all pages in memory

Thanks Andrew, I'll certainly follow your suggestion of getting used to coding into Xen context. I've just got started programming into Xen, and this will be crucial to my goal. Right now, my approach to detect a dom0 memory page is to walk across all pages in memory and identify one that holds a

Re: [PATCH] xen/arm: Using unsigned long for arm64 MPIDR mask

Hi Wei, On 05/01/2021 10:17, Wei Chen wrote: Curretly, Xen is using UINT32 for MPIDR mask to retrieve s/Curretly/Currently/ affinity[0,1,2,3] values for MPIDR_EL1 register. The value of MPIDR_EL1 is 64-bit unsigned long. The operation of 64-bit and 32-bit integers are compiler related. This

Re: [PATCH 1/2] x86/mem_sharing: copy cpuid during vm forking

On 04/01/2021 17:41, Tamas K Lengyel wrote: > Signed-off-by: Tamas K Lengyel > --- > xen/arch/x86/mm/mem_sharing.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c > index c428fd16ce..4a02c7d6f2 100644 > --- a/xen/arch/x86/mm/m

Re: [PATCH 1/2] xen/arm: Correct the coding style of get_cycles

Hi Wei, On 05/01/2021 07:19, Wei Chen wrote: It seems the arm inline function get_cycles has used 8 spaces for line indent since 2012. This patch correct them to 4 spaces and remove extra space between function name and bracket. Signed-off-by: Wei Chen Acked-by: Julien Grall Cheers, ---

Re: [PATCH 2/2] xen/arm: Add defensive barrier in get_cycles for Arm64

Hi Wei, On 05/01/2021 07:19, Wei Chen wrote: As the dicsussion [1] in mailing list. We'd better to have I would say "Per the discussion [1] on the ...". I would also suggest to replace the "." with ",". a barrier after reading CNTPCT in get_cycles. If there is not any barrier there. When g

[libvirt test] 158147: regressions - FAIL

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

Re: [PATCH 0/2] libs: implement some missing functions on FreeBSD

On Tue, Jan 05, 2021 at 11:25:44AM +0100, Roger Pau Monne wrote: > Add support for dm_op, restrict and map resource ioctls on FreeBSD. > > Roger Pau Monne (2): > libs/foreignmemory: implement the missing functions on FreeBSD > libs/devicemodel: add dm_op support for FreeBSD Acked-by: Wei Liu

Re: [PATCH v1] tools: handle more than 16T in precopy_stats

On Tue, Jan 05, 2021 at 09:30:48AM +0100, Olaf Hering wrote: > total_written tracks the number of transferred dirty pages. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu > --- > tools/include/xenguest.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/include/

Re: [PATCH v1] tools: handle more than 16T in precopy_stats

On Tue, Jan 05, 2021 at 11:54:11AM +, Wei Liu wrote: > On Tue, Jan 05, 2021 at 09:30:48AM +0100, Olaf Hering wrote: > > total_written tracks the number of transferred dirty pages. > > > > Signed-off-by: Olaf Hering > > Acked-by: Wei Liu I've added libxenguest in the commit subject line to

Re: [PATCH v1] tools: ipxe: update for fixing build with GCC10

On Mon, Jan 04, 2021 at 12:52:23PM +0100, Olaf Hering wrote: > Update to v1.21.1 to fix build in Tumbleweed, which has been broken > since months due to lack of new release. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu > --- > tools/firmware/etherboot/Makefile | 2 +- > 1 file changed, 1

Re: [XEN PATCH v2] docs: set date to SOURCE_DATE_EPOCH if available

On Thu, Dec 24, 2020 at 08:02:37PM +0100, Hans van Kranenburg wrote: > Hi, > > On 12/23/20 5:56 PM, Maximilian Engelhardt wrote: > > check if a GNU date that supports the '-u -d @...' options and syntax or > > a BSD date are available. If so, use the appropriate options for the > > date command to

Re: [XEN PATCH v2] docs: set date to SOURCE_DATE_EPOCH if available

Am Wed, 23 Dec 2020 17:56:53 +0100 schrieb Maximilian Engelhardt : > reproducible builds Just wipe all built-in timestamps. They serve no purpose. Use git hashes to refer to specific build. Olaf pgpi9LRMqJGM9.pgp Description: Digitale Signatur von OpenPGP

Re: [PATCH] libxl: cleanup remaining backend xs dirs after driver domain

On Wed, Dec 09, 2020 at 04:01:21PM +0100, Marek Marczykowski-Górecki wrote: > On Sun, Nov 08, 2020 at 03:59:42PM +0100, Marek Marczykowski-Górecki wrote: > > When device is removed, backend domain (which may be a driver domain) is > > responsible for removing backend entries from xenstore. But in c

Re: [PATCH v10 00/25] tools/xenstore: support live update for xenstored

On Tue, Dec 15, 2020 at 05:35:38PM +0100, Juergen Gross wrote: > Today Xenstore is not restartable. This means a Xen server needing an > update of xenstored has to be rebooted in order to let this update > become effective. > > This patch series is changing that: The internal state of xenstored >

Re: [PATCH] xsm/dummy: harden against speculative abuse

On Mon, Dec 21, 2020 at 02:15:55PM +0100, Jan Beulich wrote: > On 17.12.2020 12:57, Jan Beulich wrote: > > --- a/xen/include/xsm/dummy.h > > +++ b/xen/include/xsm/dummy.h > > @@ -76,20 +76,20 @@ static always_inline int xsm_default_act > > case XSM_HOOK: > > return 0; > > case XS

[PATCH v2 0/2] a tiny bit of header disentangling

While reviewing Hongyan's "x86/vmap: handle superpages in vmap_to_mfn()" it became apparent that the interaction of xen/mm.h and asm/page.h is problematic. Therefore some basic page size related definitions get moved out of the latter, and the mfn_t et al ones out of the former, each into new heade

[PATCH v2 1/2] include: don't use asm/page.h from common headers

Doing so limits what can be done in (in particular included by) this per- arch header. Abstract out page shift/size related #define-s, which is all the respective headers care about. Extend the replacement / removal to some x86 headers as well; some others now need to include page.h (and they reall

[PATCH v2 2/2] mm: split out mfn_t / gfn_t / pfn_t definitions and helpers

xen/mm.h has heavy dependencies, while in a number of cases only these type definitions are needed. This separation then also allows pulling in these definitions when including xen/mm.h would cause cyclic dependencies. Replace xen/mm.h inclusion where possible in include/xen/. (In xen/iommu.h also

[PATCH v2] vPCI/MSI-X: fold clearing of entry->updated

Both call sites clear the flag after a successfull call to update_entry(). This can be simplified by moving the clearing into the function, onto its success path. As a result of neither caller caring about update_entry()'s return value anymore, the function gets switched to return void. Signed-of

Re: [RFC] design: design doc for 1:1 direct-map

On 10/12/2020 07:02, Penny Zheng wrote: Hi Julien Hi Penny, Apologies for the late answer. Thanks for the nice and detailed comments. (*^▽^*) Here are the replies: -Original Message- From: Julien Grall Sent: Tuesday, December 8, 2020 5:07 PM To: Penny Zheng ; xen-devel@lists.x

[PATCH RFC] lib: extend ASSERT()

The increasing amount of constructs along the lines of if ( !condition ) { ASSERT_UNREACHABLE(); return; } is not only longer than necessary, but also doesn't produce incident specific console output (except for file name and line number). Allow the intended effect to

[qemu-mainline test] 158143: regressions - FAIL

flight 158143 qemu-mainline real [real] flight 158157 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158143/ http://logs.test-lab.xenproject.org/osstest/logs/158157/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

[PATCH v4 00/10] evtchn: (not so) recent XSAs follow-on

These are grouped into a series largely because of their origin, not so much because there are heavy dependencies among them. Compared to v3, there are several a new patches (in particular the simultaneous locking of two domains' event locks gets done away with) and movement of a controversial one

[PATCH v4 01/10] evtchn: use per-channel lock where possible

Neither evtchn_status() nor domain_dump_evtchn_info() nor flask_get_peer_sid() need to hold the per-domain lock - they all only read a single channel's state (at a time, in the dump case). Signed-off-by: Jan Beulich --- v4: New. --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @

[PATCH v4 02/10] evtchn: bind-interdomain doesn't need to hold both domains' event locks

The local domain's lock is needed for the port allocation, but for the remote side the per-channel lock is sufficient. The per-channel locks then need to be acquired slightly earlier, though. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.

[PATCH v4 03/10] evtchn: convert domain event lock to an r/w one

Especially for the use in evtchn_move_pirqs() (called when moving a vCPU across pCPU-s) and the ones in EOI handling in PCI pass-through code, serializing perhaps an entire domain isn't helpful when no state (which isn't e.g. further protected by the per-channel lock) changes. Unfortunately this i

[PATCH v4 04/10] evtchn: don't call Xen consumer callback with per-channel lock held

While there don't look to be any problems with this right now, the lock order implications from holding the lock can be very difficult to follow (and may be easy to violate unknowingly). The present callbacks don't (and no such callback should) have any need for the lock to be held. Signed-off-by:

[PATCH v4 05/10] evtchn: closing of vIRQ-s doesn't require looping over all vCPU-s

Global vIRQ-s have their event channel association tracked on vCPU 0. Per-vCPU vIRQ-s can't have their notify_vcpu_id changed. Hence it is well-known which vCPU's virq_to_evtchn[] needs updating. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/common/event_channel.c +++ b/xen/common/event_chan

[PATCH v4 06/10] evtchn: slightly defer lock acquire where possible

port_is_valid() and evtchn_from_port() are fine to use without holding any locks. Accordingly acquire the per-domain lock slightly later in evtchn_close() and evtchn_bind_vcpu(). Signed-off-by: Jan Beulich --- v4: New. --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -604,17

[PATCH v4 07/10] evtchn: add helper for port_is_valid() + evtchn_from_port()

The combination is pretty common, so adding a simple local helper seems worthwhile. Make it const- and type-correct, in turn requiring the two called function to also be const-correct (and at this occasion also make them type-correct). Signed-off-by: Jan Beulich --- v4: New. --- a/xen/common/eve

Re: [PATCH v2] vPCI/MSI-X: fold clearing of entry->updated

On Tue, Jan 05, 2021 at 01:39:54PM +0100, Jan Beulich wrote: > Both call sites clear the flag after a successfull call to > update_entry(). This can be simplified by moving the clearing into the > function, onto its success path. > > As a result of neither caller caring about update_entry()'s retu

[PATCH v4 08/10] evtchn: closing of ports doesn't need to hold both domains' event locks

The local domain's lock is needed for the port freeing, but for the remote side the per-channel lock is sufficient. Other logic then needs rearranging, though, including the early dropping of both locks (and the remote domain ref) in the ECS_PIRQ and ECS_VIRQ cases. Note in particular that there i

[PATCH v4 09/10] evtchn: type adjustments

First of all avoid "long" when "int" suffices, i.e. in particular when merely conveying error codes. 32-bit values are slightly cheaper to deal with on x86, and their processing is at least no more expensive on Arm. Where possible use evtchn_port_t for port numbers and unsigned int for other unsign

[PATCH v4 10/10] evtchn: drop acquiring of per-channel lock from send_guest_{global,vcpu}_virq()

The per-vCPU virq_lock, which is being held anyway, together with there not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[] is zero, provide sufficient guarantees. Undo the lock addition done for XSA-343 (commit e045199c7c9c "evtchn: address races with evtchn_reset()"). Update

[xen-unstable-smoke test] 158152: regressions - FAIL

flight 158152 xen-unstable-smoke real [real] flight 158156 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/158152/ http://logs.test-lab.xenproject.org/osstest/logs/158156/ Regressions :-( Tests which did not succeed and are blocking, including tests which co

[PATCH 0/5] domain referencing adjustments

In the course of preparing v4 of "evtchn: (not so) recent XSAs follow-on" (which is a contextual prereq to some of the patches here) I've noticed some slight inefficiencies. I've then also looked for similar patterns elsewhere. 1: common: don't (kind of) open-code rcu_lock_domain_by_any_id() 2: ev

[PATCH 1/5] common: don't (kind of) open-code rcu_lock_domain_by_any_id()

Even more so when using rcu_lock_domain_by_id() in place of the more efficient rcu_lock_current_domain(). Signed-off-by: Jan Beulich --- Besides get_pg_owner(), gnttab_copy_lock_domain() has similar strange(?) behavior: They accept DOMID_SELF, but not the resolved ID of the caller. --- v4: New.

[PATCH 2/5] evtchn: don't pointlessly use get_domain()

For short-lived references rcu_lock_domain() is the better (slightly cheaper) alternative. Signed-off-by: Jan Beulich --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -642,7 +642,7 @@ int evtchn_close(struct domain *d1, int */ write_unlock(&chn1->lo

[PATCH 3/5] argo: don't pointlessly use get_domain_by_id()

For short-lived references rcu_lock_domain_by_id() is the better (slightly cheaper) alternative. Signed-off-by: Jan Beulich --- Is it really intentional for fill_ring_data() to return success (0) in case the domain can't be found or has argo disabled? Even if so, the uninitialized ent.max_message

[PATCH 4/5] x86: don't pointlessly use get_domain_by_id()

For short-lived references rcu_lock_domain_by_id() is the better (slightly cheaper) alternative. Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mcheck/mcaction.c +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -87,7 +87,7 @@ mc_memerr_dhandler(struct mca_binfo *bin BUG_ON( bank->mc_d

[PATCH 5/5] x86/mem-sharing: don't pointlessly use get_domain_by_id()

For short-lived references rcu_lock_domain_by_id() is the better (slightly cheaper) alternative. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -537,7 +537,7 @@ static int audit(void) p2m_type_t t; mfn_t o_mfn; -

Re: [PATCH 5/5] x86/mem-sharing: don't pointlessly use get_domain_by_id()

On Tue, Jan 5, 2021 at 8:28 AM Jan Beulich wrote: > > For short-lived references rcu_lock_domain_by_id() is the better > (slightly cheaper) alternative. > > Signed-off-by: Jan Beulich Acked-by: Tamas K Lengyel

Re: [PATCH 1/5] common: don't (kind of) open-code rcu_lock_domain_by_any_id()

On 05/01/2021 13:24, Jan Beulich wrote: > Even more so when using rcu_lock_domain_by_id() in place of the more > efficient rcu_lock_current_domain(). > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper > --- > Besides get_pg_owner(), gnttab_copy_lock_domain() has similar strange(?) > behavio

RE: [PATCH] xen/arm: Using unsigned long for arm64 MPIDR mask

Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2021年1月5日 19:01 > To: Wei Chen ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org > Cc: Bertrand Marquis ; Penny Zheng > ; Jiamei Xie ; nd > > Subject: Re: [PATCH] xen/arm: Using unsigned long for arm64 MPIDR mask > >

RE: [PATCH 2/2] xen/arm: Add defensive barrier in get_cycles for Arm64

Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2021年1月5日 19:17 > To: Wei Chen ; xen-devel@lists.xenproject.org; > sstabell...@kernel.org > Cc: Bertrand Marquis ; Penny Zheng > ; Jiamei Xie ; nd > > Subject: Re: [PATCH 2/2] xen/arm: Add defensive barrier in get_cycles for >

Re: [PATCH RFC] lib: extend ASSERT()

On 05/01/2021 12:45, Jan Beulich wrote: > The increasing amount of constructs along the lines of > > if ( !condition ) > { > ASSERT_UNREACHABLE(); > return; > } > > is not only longer than necessary, but also doesn't produce incident > specific console output (except for

Re: [PATCH 1/5] common: don't (kind of) open-code rcu_lock_domain_by_any_id()

On 05.01.2021 14:38, Andrew Cooper wrote: > On 05/01/2021 13:24, Jan Beulich wrote: >> Even more so when using rcu_lock_domain_by_id() in place of the more >> efficient rcu_lock_current_domain(). >> >> Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper Thanks. >> --- >> Besides get_pg_owne

Re: [PATCH 5/5] x86/xen: Don't register PV spinlock IPI when it isn't going to be used

On 1/4/21 8:41 PM, David Woodhouse wrote: > On Mon, 2021-01-04 at 18:44 -0500, boris.ostrov...@oracle.com wrote: >> On 1/4/21 6:19 PM, David Woodhouse wrote: >>> On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com >>> wrote: Why not xen_hvm_cpu_die too? common_cpu_die() sounds like

Re: [PATCH RFC] lib: extend ASSERT()

On 05.01.2021 14:56, Andrew Cooper wrote: > On 05/01/2021 12:45, Jan Beulich wrote: >> The increasing amount of constructs along the lines of >> >> if ( !condition ) >> { >> ASSERT_UNREACHABLE(); >> return; >> } >> >> is not only longer than necessary, but also doesn't p

[PATCH v1] tools: remove get_platform_info from xg_save_restore.h

Last user was removed with commit 4ddf474e2b7c045fadeaf765ac6157de745e84d6 Previously it was also used in migration code, which was removed with commit b15bc4345e772df92e5ffdbc4c1e9ae2a6206617 Signed-off-by: Olaf Hering --- tools/libs/guest/xg_domain.c | 2 +- tools/libs/guest/xg_save_res

[PATCH v1] tools: remove FOLD_CR3 from xg_save_restore.h

The last user was removed with commit b15bc4345e772df92e5ffdbc4c1e9ae2a6206617 Signed-off-by: Olaf Hering --- tools/libs/guest/xg_save_restore.h | 10 -- 1 file changed, 10 deletions(-) diff --git a/tools/libs/guest/xg_save_restore.h b/tools/libs/guest/xg_save_restore.h index e4fe747c4

[PATCH v1] tools: move M2P macros to xg_private.h

Just code movement as a preparatory change before xg_sr_* will be moved. Signed-off-by: Olaf Hering --- tools/libs/guest/xg_private.h | 10 ++ tools/libs/guest/xg_save_restore.h | 10 -- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/tools/libs/guest/xg_pri

[PATCH v2] x86: drop use of E801 memory "map" (and alike)

ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware has been observed to include E820_ACPI ranges in what E801 reports as available (really "configured") memory. Since all 64-bit systems ought to support ACPI, drop our use of older BIOS and boot loader interfaces. Signed-off-by: J

Re: [PATCH 5/5] x86/xen: Don't register PV spinlock IPI when it isn't going to be used

On Tue, 2021-01-05 at 09:45 -0500, boris.ostrov...@oracle.com wrote: > For maintenance purposes. When something gets added in initialization > path (prepare_boot_cpu() and such) we likely want to tear it down in > cpu_die(). Today both native and Xen cpu_die() ops work the same but > things change.

[PATCH v1] tools: create libxensaverestore

Move all save/restore related code from libxenguest.so into a separate library. The only consumer is libxl-save-helper. There is no need to have the moved code mapped all the time in binaries where libxenguest.so is used. Signed-off-by: Olaf Hering --- The M2P defines are also moved with a separ

Re: [PATCH v1] tools: create libxensaverestore

Am Tue, 5 Jan 2021 16:37:44 +0100 schrieb Olaf Hering : > -/* > - * A precopy_policy callback may not be running in the same address > - * space as libxc an so precopy_stats is passed by value. > - */ > -typedef int (*precopy_policy_t)(struct precopy_stats, void *); Does anyone happen what that

RE: [PATCH 1/2] x86/mem_sharing: copy cpuid during vm forking

> -Original Message- > From: Andrew Cooper > Sent: Tuesday, January 5, 2021 6:05 AM > To: Lengyel, Tamas ; xen- > de...@lists.xenproject.org > Cc: Tamas K Lengyel ; Jan Beulich > ; George Dunlap ; Roger > Pau Monné ; Wei Liu > Subject: Re: [PATCH 1/2] x86/mem_sharing: copy cpuid during

Re: [PATCH 1/4] xen/dmalloc: Introduce dmalloc() APIs

On 23.12.2020 17:34, Andrew Cooper wrote: > RFC: > * This probably wants to be less fatal in release builds I'm not even convinced this wants to be a panic() in debug builds. > * In an ideal world, we'd also want to count the total number of bytes >allocated from the xmalloc heap, which wou

Re: [PATCH 1/4] xen/dmalloc: Introduce dmalloc() APIs

On 23.12.2020 17:34, Andrew Cooper wrote: > --- /dev/null > +++ b/xen/common/dmalloc.c > @@ -0,0 +1,19 @@ > +#include > +#include > +#include > + > +void dfree(struct domain *d, void *ptr) > +{ > +atomic_dec(&d->dalloc_heap); > +xfree(ptr); > +} > + > +void *_dzalloc(struct domain *d, si

Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)

(+ Ian and Andre) Hi Bertrand, On IRC, Ian pointed out that the smoke test was failing on Cubietruck. The only patches because the last success and the failure are your series. This seems to be a very early failure as there is no output from Xen [1]. I originally thought the problem was beca

Re: [PATCH 2/4] xen/evtchn: Switch to dmalloc

On 23.12.2020 17:34, Andrew Cooper wrote: > RFC: Likely more to convert. This is just a minimal attempt. Looks complete as far as this one file goes. More can be found in evtchn_fifo.c of course. > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -16,6 +16,7 @@ > > #in

Re: Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)

On 05/01/2021 16:06, Julien Grall wrote: > (+ Ian and Andre) > > Hi Bertrand, > > On IRC, Ian pointed out that the smoke test was failing on Cubietruck. > The only patches because the last success and the failure are your series. > > This seems to be a very early failure as there is no output fr

Re: [PATCH 3/4] xen/domctl: Introduce fault_ttl

On 23.12.2020 17:34, Andrew Cooper wrote: > To inject a simulated resource failure, for testing purposes. > > Given a specific set of hypercall parameters, the failure is in a repeatable > position, for the currently booted Xen. The exact position of failures is > highly dependent on the build of

[xen-unstable-smoke test] 158164: regressions - FAIL

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

[linux-linus test] 158150: regressions - FAIL

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

[PATCH v7 0/7] xl / libxl: named PCI pass-through devices

From: Paul Durrant These are re-worked versions of the remaining patches from v6 of the series that were reverted by commit ac6a0af3870b "Revert patches that break libxl API". Paul Durrant (7): docs/man: modify xl(1) in preparation for naming of assignable devices libxlu: introduce xlu_pci_p

[PATCH v7 1/7] docs/man: modify xl(1) in preparation for naming of assignable devices

From: Paul Durrant A subsequent patch will introduce code to allow a name to be specified to 'xl pci-assignable-add' such that the assignable device may be referred to by than name in subsequent operations. Signed-off-by: Paul Durrant Acked-by: Wei Liu --- Cc: Ian Jackson --- docs/man/xl.1.p

[PATCH v7 3/7] libxl: stop setting 'vdevfn' in pci_struct_fill()

From: Paul Durrant There are only two call-sites. One always sets it to 0 (which is unnecessary as the structure is already initialized to zero) and the other can simply set the 'vdevfn' field directly (after proper structure initialization), avoiding the need for a local variable. A subsequent

[PATCH v7 2/7] libxlu: introduce xlu_pci_parse_spec_string()

From: Paul Durrant This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters it via the newly introduced function. The new parser also deals with 'bdf' and 'vslot' as non-positional paramaters, as per the documentation in xl-pci-configuration(5). The existing xlu_pci_parse_bdf(

[PATCH v7 5/7] xl: support naming of assignable devices

From: Paul Durrant With this patch applied 'xl pci-assignable-add' will take an optional '--name' parameter, 'xl pci-assignable-remove' can be passed either a BDF or a name and 'xl pci-assignable-list' will take a optional '--show-names' flag which determines whether names are displayed in its ou

[PATCH v7 6/7] docs/man: modify xl-pci-configuration(5) to add 'name' field to PCI_SPEC_STRING

From: Paul Durrant Since assignable devices can be named, a subsequent patch will support use of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In this case the name will be used to look up the 'bdf' in the list of assignable (or assigned) devices. Signed-off-by: Paul Durran

[PATCH v7 4/7] libxl: add 'name' field to 'libxl_device_pci' in the IDL...

From: Paul Durrant ... and modify libxl_pci_bdf_assignable_add/remove/list() to make use of it. libxl_pci_bdf_assignable_add() will store the name of the device in xenstore if the field is specified (i.e. non-NULL) and libxl_pci_bdf_assignable_remove() will remove devices specified only by name,

[PATCH v7 7/7] libxl / libxlu: support 'xl pci-attach/detach' by name

From: Paul Durrant This patch modifies libxlu_pci_parse_spec_string() to parse the new 'name' parameter of PCI_SPEC_STRING detailed in the updated documention in xl-pci-configuration(5) and populate the 'name' field of 'libxl_device_pci'. If the 'name' field is non-NULL then both libxl_device_pc

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

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

[ovmf test] 158165: all pass - PUSHED

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

[PATCH] x86/dpci: EOI interrupt regardless of it's masking status

Modify hvm_pirq_eoi to always EOI the interrupt if required, instead of not doing such EOI if the interrupt is routed through the vIO-APIC and the entry is masked at the time the EOI is performed. Further unmask of the vIO-APIC pin won't EOI the interrupt, and thus the guest OS has to wait for the

Re: Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)

On Tue, 5 Jan 2021, André Przywara wrote: > On 05/01/2021 16:06, Julien Grall wrote: > > (+ Ian and Andre) > > > > Hi Bertrand, > > > > On IRC, Ian pointed out that the smoke test was failing on Cubietruck. > > The only patches because the last success and the failure are your series. > > > > Th

[PATCH] xen/arm: do not read MVFR2 on arm32

MVFR2 is not available on arm32. Don't try to read it. Make MVFR2 arm64 only. Fixes: 9cfdb489af81 ("xen/arm: Add ID registers and complete cpuinfo") Signed-off-by: Stefano Stabellini --- xen/arch/arm/cpufeature.c| 2 ++ xen/include/asm-arm/cpufeature.h | 2 +- 2 files changed, 3 insertio

Re: Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)

Hi Stefano, On 05/01/2021 18:44, Stefano Stabellini wrote: On Tue, 5 Jan 2021, André Przywara wrote: On 05/01/2021 16:06, Julien Grall wrote: (+ Ian and Andre) Hi Bertrand, On IRC, Ian pointed out that the smoke test was failing on Cubietruck. The only patches because the last success and th

Re: [PATCH] xen/arm: do not read MVFR2 on arm32

On 05/01/2021 19:05, Stefano Stabellini wrote: MVFR2 is not available on arm32. Don't try to read it. Make MVFR2 arm64 only. Not really, MVFR2 is allocated when running in AArch32 mode on Armv8. It just doesn't exist on Armv7. See my answer your previous e-mail for more details. Fixes:

[xen-unstable-smoke test] 158168: regressions - FAIL

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

[PATCH v2] x86/mem_sharing: copy cpuid and msrs during vm forking

Signed-off-by: Tamas K Lengyel --- xen/arch/x86/mm/mem_sharing.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index c428fd16ce..fc7b2a4102 100644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -1764

Re: Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)

On Tue, 5 Jan 2021, Julien Grall wrote: > Hi Stefano, > > On 05/01/2021 18:44, Stefano Stabellini wrote: > > On Tue, 5 Jan 2021, André Przywara wrote: > > > On 05/01/2021 16:06, Julien Grall wrote: > > > > (+ Ian and Andre) > > > > > > > > Hi Bertrand, > > > > > > > > On IRC, Ian pointed out tha

Re: [XEN PATCH v2] docs: set date to SOURCE_DATE_EPOCH if available

On Dienstag, 5. Januar 2021 13:00:34 CET Wei Liu wrote: > On Thu, Dec 24, 2020 at 08:02:37PM +0100, Hans van Kranenburg wrote: > > Hi, > > > > On 12/23/20 5:56 PM, Maximilian Engelhardt wrote: > > > check if a GNU date that supports the '-u -d @...' options and syntax or > > > a BSD date are avail

[PATCH 0/3] automation: build qemu-system-aarch64 and use it for tests

Hi all, Currently we are using Debian's qemu-system-aarch64 for our tests. However, sometimes it crashes. See for instance https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/939556527. It is hard to debug and even harder to apply any fixes to it. Instead, build our own QEMU as one of our te

[PATCH 1/3] automation: add qemu-system-aarch64 to test-artifacts

Currently we are using Debian's qemu-system-aarch64 for our tests. However, sometimes it crashes. It is hard to debug and even harder to apply any fixes to it. Instead, build our own QEMU as one of our test-artifacts, which are only built once, then imported into each pipeline via phony jobs. Sig

[PATCH 3/3] automation: use test-artifacts/qemu-system-aarch64 instead of Debian's

Instead apt-get'ing Debian's qemu-system-aarch64, simply use the provided QEMU binary under binaries. Signed-off-by: Stefano Stabellini --- automation/scripts/qemu-alpine-arm64.sh | 12 +--- automation/scripts/qemu-smoke-arm64.sh | 15 +++ 2 files changed, 12 insertions(+),

[PATCH 2/3] automation: add a job to import qemu-system-aarch64 into the pipeline

In order to use the pre-built test-artifacts/qemu-system-aarch64 binary for our tests, first we need to import it into the pipeline. Let's do that the same way we did it for the kernel and Alpine Linux filesystem: by creating a special job for it. Signed-off-by: Stefano Stabellini --- automation

[PATCH v2 3/5] x86/xen: Add a no_vector_callback option to test PCI INTX delivery

From: David Woodhouse It's useful to be able to test non-vector event channel delivery, to make sure Linux will work properly on older Xen which doesn't have it. It's also useful for those working on Xen and Xen-compatible hypervisors, because there are guest kernels still in active use which us

[PATCH v2 4/5] x86/xen: Don't register Xen IPIs when they aren't going to be used

From: David Woodhouse In the case where xen_have_vector_callback is false, we still register the IPI vectors in xen_smp_intr_init() for the secondary CPUs even though they aren't going to be used. Stop doing that. Signed-off-by: David Woodhouse --- arch/x86/xen/enlighten_hvm.c | 4 ++-- 1 file

[PATCH v2 5/5] x86/xen: Fix xen_hvm_smp_init() when vector callback not available

From: David Woodhouse Only the IPI-related functions in the smp_ops should be conditional on the vector callback being available. The rest should still happen: • xen_hvm_smp_prepare_boot_cpu() This function does two things, both of which should still happen if there is no vector callback

[PATCH v2 2/5] xen: Set platform PCI device INTX affinity to CPU0

From: David Woodhouse With INTX or GSI delivery, Xen uses the event channel structures of CPU0. If the interrupt gets handled by Linux on a different CPU, then no events are seen as pending. Rather than introducing locking to allow other CPUs to process CPU0's events, just ensure that the PCI in

[PATCH v2 0/5] Xen INTX/GSI event channel delivery fixes

Fix various breakages with INTX/GSI event channel interrupt delivery, and add a command line option to test it so that it hopefully doesn't get so broken again. Karim attempted to rip this out in 2017 but put it back because it's still necessary with older versions of Xen. This fixes it properly,

  1   2   >