[PATCH v4 3/3] hw: replace most qemu_bh_new calls with qemu_bh_new_guarded

This protects devices from bh->mmio reentrancy issues. Signed-off-by: Alexander Bulekov --- hw/9pfs/xen-9p-backend.c| 4 +++- hw/block/dataplane/virtio-blk.c | 3 ++- hw/block/dataplane/xen-block.c | 5 +++-- hw/block/virtio-blk.c | 5 +++-- hw/char/virtio-serial-bus.c |

Re: [PATCH 0/6] tools: Switch to non-truncating XENVER_* ops

On 17.01.23 14:53, Andrew Cooper wrote: This is the tools side of the Xen series posted previously. With this, a Xen built with long strings can be retrieved: # xl info ... xen_version: 4.18-unstable+REALLY LONG EXTRAVERSION xen_changeset : Tue Jan 3 19:27:17

RE: [PATCH] x86/vmx: Partially revert "x86/vmx: implement Notify VM Exit"

> From: Andrew Cooper > Sent: Thursday, January 19, 2023 3:37 AM > > The original patch tried to do two things - implement VMNotify, and > re-optimise VT-x to not intercept #DB/#AC by default. > > The second part is buggy in multiple ways. Both GDBSX and Introspection > need > to conditionally

[ovmf test] 175964: all pass - PUSHED

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

[linux-5.4 test] 175958: regressions - FAIL

flight 175958 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/175958/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 175560 build-i386-xsm

[linux-linus test] 175957: regressions - FAIL

flight 175957 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/175957/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462

[xen-unstable test] 175956: regressions - FAIL

flight 175956 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175956/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken in 175948 build-armhf4

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

On 1/17/2023 11:27 PM, Alex Williamson wrote: > On Tue, 17 Jan 2023 19:15:57 -0500 > Chuck Zmudzinski wrote: > > > On 1/17/2023 6:04 AM, Igor Mammedov wrote: > > > On Mon, 16 Jan 2023 13:00:53 -0500 > > > Chuck Zmudzinski wrote: > > > > > > > On 1/16/23 10:33, Igor Mammedov wrote: > > > > >

[qemu-upstream-unstable test] 175954: regressions - trouble: blocked/broken/fail/pass

flight 175954 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175954/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-xsm

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

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

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

On 18/01/2023 6:21 pm, Anthony PERARD wrote: > On Tue, Jan 17, 2023 at 05:21:32PM +, Andrew Cooper wrote: >> On 16/01/2023 6:10 pm, Anthony PERARD wrote: >>> +def get_typedefs(tokens): >>> +level = 1 >>> +state = 0 >>> +typedefs = [] >> I'm pretty sure typedefs actually wants to be

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

On 18/01/2023 8:06 am, Jan Beulich wrote: > On 17.01.2023 18:21, Andrew Cooper wrote: >> On 16/01/2023 6:10 pm, Anthony PERARD wrote: >>> +elif re.match(r'^[a-zA-Z_]', token): >> [...] >> >> All of this said, where is 0-9 in the token regex?  Have we just got >> extremely lucky with having

[PATCH] x86/vmx: Partially revert "x86/vmx: implement Notify VM Exit"

The original patch tried to do two things - implement VMNotify, and re-optimise VT-x to not intercept #DB/#AC by default. The second part is buggy in multiple ways. Both GDBSX and Introspection need to conditionally intercept #DB, which was not accounted for. Also, #DB interception has nothing

[qemu-mainline test] 175952: regressions - FAIL

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

Re: [RFC PATCH 00/10] Rework PCI locking

Hi Jan, On 06/09/2022 11:32, Jan Beulich wrote: On 31.08.2022 16:10, Volodymyr Babchuk wrote: Hello, This is yet another take to a PCI locking rework. This approach was suggest by Jan Beulich who proposed to use a reference counter to control lifetime of pci_dev objects. When I started added

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

On Tue, Jan 17, 2023 at 05:21:32PM +, Andrew Cooper wrote: > On 16/01/2023 6:10 pm, Anthony PERARD wrote: > > +def get_typedefs(tokens): > > +level = 1 > > +state = 0 > > +typedefs = [] > > I'm pretty sure typedefs actually wants to be a dict rather than a list > (will have better

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

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

[ovmf test] 175960: all pass - PUSHED

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

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

On Wed, Jan 18, 2023 at 1:58 PM Jan Beulich wrote: > On 18.01.2023 14:34, George Dunlap wrote: > > On Wed, Jan 18, 2023 at 1:15 PM Jan Beulich wrote: > > > >> On 18.01.2023 12:15, Ayan Kumar Halder wrote: > >>> On 18/01/2023 08:40, Jan Beulich wrote: > On 17.01.2023 18:43, Ayan Kumar

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On Wed, 2023-01-18 at 14:39 +, Andrew Cooper wrote: > On 18/01/2023 2:26 pm, David Woodhouse wrote:? > > > There is no actual thing called PVHVM.  That diagram has caused far more > > > damage than good... > > > > > > There's HVM (and by this, I mean the hypervisor's interpretation meaning > >

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On 18/01/2023 2:26 pm, David Woodhouse wrote: > On Wed, 2023-01-18 at 14:22 +, Andrew Cooper wrote: >> On 18/01/2023 2:06 pm, David Woodhouse wrote: >>> On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote: On 18/01/2023 12:22 pm, David Woodhouse wrote: > Signed-off-by: David

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On Wed, 2023-01-18 at 14:22 +, Andrew Cooper wrote: > On 18/01/2023 2:06 pm, David Woodhouse wrote: > > On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote: > > > On 18/01/2023 12:22 pm, David Woodhouse wrote: > > > > Signed-off-by: David Woodhouse > > > > --- > > > > What does

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On 18/01/2023 2:06 pm, David Woodhouse wrote: > On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote: >> On 18/01/2023 12:22 pm, David Woodhouse wrote: >>> Signed-off-by: David Woodhouse >>> --- >>> What does xen_evtchn_do_upcall() exist for? Can we delete it? I don't >>> see it being called

Re: [PATCH v2 9/9] x86/shadow: harden shadow_size()

On 17.01.2023 20:13, Andrew Cooper wrote: > On 12/01/2023 10:42 am, Jan Beulich wrote: >> On 12.01.2023 11:31, Andrew Cooper wrote: >>> On 12/01/2023 9:47 am, Jan Beulich wrote: On 12.01.2023 00:15, Andrew Cooper wrote: > On 11/01/2023 1:57 pm, Jan Beulich wrote: >> Make HVM=y release

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote: > On 18/01/2023 12:22 pm, David Woodhouse wrote: > > Signed-off-by: David Woodhouse > > --- > > What does xen_evtchn_do_upcall() exist for? Can we delete it? I don't > > see it being called anywhere. > > Seems the caller was dropped by >

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

On 18.01.2023 14:34, George Dunlap wrote: > On Wed, Jan 18, 2023 at 1:15 PM Jan Beulich wrote: > >> On 18.01.2023 12:15, Ayan Kumar Halder wrote: >>> On 18/01/2023 08:40, Jan Beulich wrote: On 17.01.2023 18:43, Ayan Kumar Halder wrote: > @@ -1166,7 +1166,7 @@ static const struct

Re: [PATCH] xen: Allow platform PCI interrupt to be shared

On 18/01/2023 12:22 pm, David Woodhouse wrote: > Signed-off-by: David Woodhouse > --- > What does xen_evtchn_do_upcall() exist for? Can we delete it? I don't > see it being called anywhere. Seems the caller was dropped by cb09ea2924cbf1a42da59bd30a59cc1836240bcb, but the CONFIG_PVHVM looks bogus

Re: [PATCH 2/6] tools: Introduce a non-truncating xc_xenver_extraversion()

> On 17 Jan 2023, at 13:53, Andrew Cooper wrote: > > ... which uses XENVER_extraversion2. > > In order to do sensibly, use manual hypercall buffer handling. Not only does > this avoid an extra bounce buffer (we need to strip the xen_varbuf_t header > anyway), it's also shorter and easlier

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

On Wed, Jan 18, 2023 at 1:15 PM Jan Beulich wrote: > On 18.01.2023 12:15, Ayan Kumar Halder wrote: > > On 18/01/2023 08:40, Jan Beulich wrote: > >> On 17.01.2023 18:43, Ayan Kumar Halder wrote: > >>> @@ -1166,7 +1166,7 @@ static const struct ns16550_config __initconst > uart_config[] = > >>>

Re: [PATCH 4/6] tools: Introduce a non-truncating xc_xenver_changeset()

> On 17 Jan 2023, at 13:53, Andrew Cooper wrote: > > Update libxl and the ocaml stubs to match. No API/ABI change in either. > > Signed-off-by: Andrew Cooper Acked-by: Christian Lindig > --- > CC: Wei Liu > CC: Anthony PERARD > CC: Juergen Gross > CC: Christian Lindig > CC: David

Re: [PATCH 3/6] tools: Introduce a non-truncating xc_xenver_capabilities()

> On 17 Jan 2023, at 13:53, Andrew Cooper wrote: > > Update libxl and the ocaml stubs to match. No API/ABI change in either. > > Signed-off-by: Andrew Cooper > --- > CC: Wei Liu > CC: Anthony PERARD > CC: Juergen Gross > CC: Christian Lindig > CC: David Scott > CC: Edwin Torok > CC:

Re: [PATCH 0/6] tools: Switch to non-truncating XENVER_* ops

I will look at individual patches, too. > On 17 Jan 2023, at 13:53, Andrew Cooper wrote: > > This is the tools side of the Xen series posted previously. > > With this, a Xen built with long strings can be retrieved: > > # xl info > ... > xen_version: 4.18-unstable+REALLY LONG

Re: [XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

On 18.01.2023 12:57, Ayan Kumar Halder wrote: > Hi Jan, > > On 18/01/2023 08:50, Jan Beulich wrote: >> On 17.01.2023 18:43, Ayan Kumar Halder wrote: >>> --- a/xen/arch/arm/include/asm/types.h >>> +++ b/xen/arch/arm/include/asm/types.h >>> @@ -37,9 +37,16 @@ typedef signed long long s64; >>>

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

On 18.01.2023 12:15, Ayan Kumar Halder wrote: > On 18/01/2023 08:40, Jan Beulich wrote: >> On 17.01.2023 18:43, Ayan Kumar Halder wrote: >>> @@ -1166,7 +1166,7 @@ static const struct ns16550_config __initconst >>> uart_config[] = >>> static int __init >>> pci_uart_config(struct ns16550 *uart,

Re: [PATCH v4 1/4] xen/riscv: introduce asm/types.h header file

On 18.01.2023 12:23, Oleksii wrote: > On Tue, 2023-01-17 at 11:04 +0100, Jan Beulich wrote: >> On 17.01.2023 10:29, Oleksii wrote: >>> On Mon, 2023-01-16 at 15:59 +0100, Jan Beulich wrote: On 16.01.2023 15:39, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko > --- >

[ovmf test] 175959: regressions - FAIL

flight 175959 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175959/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 175747 build-amd64

[PATCH] xen: Allow platform PCI interrupt to be shared

From: David Woodhouse When we don't use the per-CPU vector callback, we ask Xen to deliver event channel interrupts as INTx on the PCI platform device. As such, it can be shared with INTx on other PCI devices. Set IRQF_SHARED, and make it return IRQ_HANDLED or IRQ_NONE according to whether the

[ovmf test] 175955: regressions - FAIL

flight 175955 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/175955/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 175747 build-i386

Re: [XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

Hi Jan, On 18/01/2023 08:50, Jan Beulich wrote: On 17.01.2023 18:43, Ayan Kumar Halder wrote: --- a/xen/arch/arm/include/asm/types.h +++ b/xen/arch/arm/include/asm/types.h @@ -37,9 +37,16 @@ typedef signed long long s64; typedef unsigned long long u64; typedef u32 vaddr_t; #define

Re: [PATCH v2 1/7] x86/boot: Remove verify_cpu() from secondary_startup_64()

On Wed, Jan 18, 2023 at 10:45:44AM +0100, Peter Zijlstra wrote: > On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote: > > The boot trampolines from trampoline_64.S have code flow like: > > > > 16bit BIOSSEV-ES 64bit > > EFI > > > >

RE: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity map sections

Hi Julien, > -Original Message- > >>> > >>> In this patch we introduce .text.idmap to head_mmu.S, and > >>> add this section after .text.header. to ensure code of > >>> head_mmu.S after the code of header.S. > >>> > >>> After this, we will still include some code that does not > >>>

Re: [PATCH v4 2/4] xen/riscv: introduce sbi call to putchar to console

On Wed, 2023-01-18 at 08:38 +0100, Jan Beulich wrote: > On 18.01.2023 00:32, Andrew Cooper wrote: > > On 16/01/2023 2:39 pm, Oleksii Kurochko wrote: > > > +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid, > > > +    unsigned long arg0, unsigned long arg1, > > > +   

RE: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

Hi Julien, > -Original Message- > From: Xen-devel On Behalf Of > Julien Grall > Sent: 2023年1月18日 19:00 > To: Wei Chen ; Penny Zheng ; xen- > de...@lists.xenproject.org > Cc: Stefano Stabellini ; Bertrand Marquis > ; Volodymyr Babchuk ; > Jiamei Xie > Subject: Re: [PATCH v2 04/40]

Re: [PATCH v4 1/4] xen/riscv: introduce asm/types.h header file

On Tue, 2023-01-17 at 11:04 +0100, Jan Beulich wrote: > On 17.01.2023 10:29, Oleksii wrote: > > On Mon, 2023-01-16 at 15:59 +0100, Jan Beulich wrote: > > > On 16.01.2023 15:39, Oleksii Kurochko wrote: > > > > Signed-off-by: Oleksii Kurochko > > > > --- > > > > Changes in V4: > > > >     - Clean

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

Hi Jan, On 18/01/2023 08:40, Jan Beulich wrote: On 17.01.2023 18:43, Ayan Kumar Halder wrote: One should now be able to use 'paddr_t' to represent address and size. Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t. Signed-off-by: Ayan Kumar Halder --- Changes from -

Re: [PATCH v4 3/4] xen/riscv: introduce early_printk basic stuff

On Tue, 2023-01-17 at 23:57 +, Andrew Cooper wrote: > On 16/01/2023 2:39 pm, Oleksii Kurochko wrote: > > diff --git a/xen/arch/riscv/Kconfig.debug > > b/xen/arch/riscv/Kconfig.debug > > index e69de29bb2..e139e44873 100644 > > --- a/xen/arch/riscv/Kconfig.debug > > +++

Re: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

Hi, On 18/01/2023 10:22, Wei Chen wrote: Although it is unlikely that vendors using the Armv8-R IP will do so, it is indeed an option. In the ID register, there are also related bits in ID_AA64MMFR0_EL1 (MSA_frac) to indicate this. --- xen/arch/arm/Kconfig | 8

Re: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity map sections

On 18/01/2023 02:18, Wei Chen wrote: Hi Julien, Hi Wei, -Original Message- From: Julien Grall Sent: 2023年1月18日 7:46 To: Penny Zheng ; xen-devel@lists.xenproject.org Cc: Wei Chen ; Stefano Stabellini ; Bertrand Marquis ; Volodymyr Babchuk Subject: Re: [PATCH v2 07/40] xen/arm64: add

[xen-unstable test] 175948: regressions - trouble: blocked/broken/fail/pass

flight 175948 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/175948/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 4

RE: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related code from head.S

Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2023年1月18日 17:50 > To: Wei Chen ; Penny Zheng ; xen- > de...@lists.xenproject.org > Cc: Stefano Stabellini ; Bertrand Marquis > ; Volodymyr Babchuk > Subject: Re: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related >

RE: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

Hi Julien, > -Original Message- > From: Julien Grall > Sent: 2023年1月18日 17:44 > To: Wei Chen ; Penny Zheng ; xen- > de...@lists.xenproject.org > Cc: Stefano Stabellini ; Bertrand Marquis > ; Volodymyr Babchuk ; > Jiamei Xie > Subject: Re: [PATCH v2 04/40] xen/arm: add an option to

Re: [PATCH v2 0/6] Resolve TYPE_PIIX3_XEN_DEVICE

On Wed, Jan 04, 2023 at 03:44:31PM +0100, Bernhard Beschow wrote: > This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes > it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the > PC > machine agnostic to the precise southbridge being used. 2/ will

Re: [XEN v2 00/11] Add support for 32 bit physical address

Hi Ayan, On 17/01/2023 18:43, Ayan Kumar Halder wrote: > > > Hi All, > > Please have a look at > https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html > for the context. > > The benefits of using 32 bit physical addresses are as follows :- > > 1. It helps to use Xen on

Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas

On 17.01.2023 23:20, Andrew Cooper wrote: > On 24/11/2022 9:29 pm, Julien Grall wrote: >> On 19/10/2022 09:43, Jan Beulich wrote: >>> The registration by virtual/linear address has downsides: At least on >>> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit >>> PV domains the

Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas

On 17.01.2023 23:04, Andrew Cooper wrote: > On 19/10/2022 8:43 am, Jan Beulich wrote: >> The registration by virtual/linear address has downsides: At least on >> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit >> PV domains the areas are inaccessible (and hence cannot be

[PATCH v4 14/17] tools/xenstore: introduce trace classes

Make the xenstored internal trace configurable by adding classes which can be switched on and off independently from each other. Define the following classes: - obj: Creation and deletion of interesting "objects" (watch, transaction, connection) - io: incoming requests and outgoing responses -

[PATCH v4 13/17] tools/xenstore: switch hashtable to use the talloc framework

Instead of using malloc() and friends, let the hashtable implementation use the talloc framework. This is more consistent with the rest of xenstored and it allows to track memory usage via "xenstore-control memreport". Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- V3: - make key

[PATCH v4 15/17] tools/xenstore: let check_store() check the accounting data

Today check_store() is only testing the correctness of the node tree. Add verification of the accounting data (number of nodes) and correct the data if it is wrong. Do the initial check_store() call only after Xenstore entries of a live update have been read. This is wanted to make sure the

[PATCH v4 08/17] tools/xenstore: change per-domain node accounting interface

Rework the interface and the internals of the per-domain node accounting: - rename the functions to domain_nbentry_*() in order to better match the related counter name - switch from node pointer to domid as interface, as all nodes have the owner filled in - use a common internal function

[PATCH v4 12/17] tools/xenstore: don't let hashtable_remove() return the removed value

Letting hashtable_remove() return the value of the removed element is not used anywhere in Xenstore, and it conflicts with a hashtable created specifying the HASHTABLE_FREE_VALUE flag. So just drop returning the value. This of course requires to free the value if the HASHTABLE_FREE_VALUE was

[PATCH v4 11/17] tools/xenstore: let chk_domain_generation() return a bool

Instead of returning 0 or 1 let chk_domain_generation() return a boolean value. Simplify the only caller by removing the ret variable. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- tools/xenstore/xenstored_domain.c | 18 -- 1 file changed, 8 insertions(+), 10

[PATCH v4 09/17] tools/xenstore: replace literal domid 0 with dom0_domid

There are some places left where dom0 is associated with domid 0. Use dom0_domid instead. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- tools/xenstore/xenstored_core.c | 5 +++-- tools/xenstore/xenstored_domain.c | 8 2 files changed, 7 insertions(+), 6 deletions(-)

[PATCH v4 16/17] tools/xenstore: make output of "xenstore-control help" more pretty

Using a tab for separating the command from the options in the output of "xenstore-control help" results in a rather ugly list. Use a fixed size for the command instead. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- V2: - new patch --- tools/xenstore/xenstored_control.c | 2 +- 1

[PATCH v4 17/17] tools/xenstore: don't allow creating too many nodes in a transaction

The accounting for the number of nodes of a domain in an active transaction is not working correctly, as it allows to create arbitrary number of nodes. The transaction will finally fail due to exceeding the number of nodes quota, but before closing the transaction an unprivileged guest could cause

[PATCH v4 10/17] tools/xenstore: make domain_is_unprivileged() an inline function

clang 14 is complaining about a NULL dereference for constructs like: domain_is_unprivileged(conn) ? conn->in : NULL as it can't know that domain_is_unprivileged(conn) will return false if conn is NULL. Fix that by making domain_is_unprivileged() an inline function (and related to that

[PATCH v4 07/17] tools/xenstore: move changed domain handling

Move all code related to struct changed_domain from xenstored_transaction.c to xenstored_domain.c. This will be needed later in order to simplify the accounting data updates in cases of errors during a request. Split the code to have a more generic base framework. Signed-off-by: Juergen Gross

[PATCH v4 06/17] tools/xenstore: replace watch->relative_path with a prefix length

Instead of storing a pointer to the path which is prepended to relative paths in struct watch, just use the length of the prepended path. It should be noted that the now removed special case of the relative path being "" in get_watch_path() can't happen at all. Signed-off-by: Juergen Gross

[PATCH v4 05/17] tools/xenstore: introduce dummy nodes for special watch paths

Instead of special casing the permission handling and watch event firing for the special watch paths "@introduceDomain" and "@releaseDomain", use static dummy nodes added to the data base when starting Xenstore. The node accounting needs to reflect that change by adding the special nodes in the

[PATCH v4 04/17] tools/xenstore: make log macro globally available

Move the definition of the log() macro to xenstored_core.h in order to make it usable from other source files, too. While at it preserve errno from being modified. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- tools/xenstore/xenstored_core.c | 14 --

[PATCH v4 03/17] tools/xenstore: add hashlist for finding struct domain by domid

Today finding a struct domain by its domain id requires to scan the list of domains until finding the correct domid. Add a hashlist for being able to speed this up. This allows to remove the linking of struct domain in a list. Note that the list of changed domains per transaction is kept as a

[PATCH v4 01/17] tools/xenstore: let talloc_free() preserve errno

Today talloc_free() is not guaranteed to preserve errno, especially in case a custom destructor is being used. So preserve errno in talloc_free(). This allows to remove some errno saving outside of talloc.c. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- V2: - drop wrapper (Julien

[PATCH v4 02/17] tools/xenstore: remove all watches when a domain has stopped

When a domain has been released by Xen tools, remove all its registered watches. This avoids sending watch events to the dead domain when all the nodes related to it are being removed by the Xen tools. Signed-off-by: Juergen Gross Reviewed-by: Julien Grall --- V2: - move call to do_release()

[PATCH v4 00/17] tools/xenstore: do some cleanup and fixes

This is a first run of post-XSA patches which piled up during the development phase of all the recent Xenstore related XSA patches. This is a mixture of small fixes, enhancements and cleanups. Changes in V4: - reordered the patches a little bit (patch 4 and patch 17 of V4 have been moved) -

Re: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related code from head.S

On 18/01/2023 03:09, Wei Chen wrote: Hi Julien, -Original Message- From: Julien Grall Sent: 2023年1月18日 7:37 To: Penny Zheng ; xen-devel@lists.xenproject.org Cc: Wei Chen ; Stefano Stabellini ; Bertrand Marquis ; Volodymyr Babchuk Subject: Re: [PATCH v2 05/40] xen/arm64: prepare

Re: [PATCH v2 1/7] x86/boot: Remove verify_cpu() from secondary_startup_64()

On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote: > The boot trampolines from trampoline_64.S have code flow like: > > 16bit BIOS SEV-ES 64bit EFI > > trampoline_start() sev_es_trampoline_start() > trampoline_start_64()

Re: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

On 18/01/2023 03:00, Wei Chen wrote: Hi Julien, Hi Wei, -Original Message- From: Julien Grall Sent: 2023年1月18日 7:24 To: Penny Zheng ; xen-devel@lists.xenproject.org Cc: Wei Chen ; Stefano Stabellini ; Bertrand Marquis ; Volodymyr Babchuk ; Jiamei Xie Subject: Re: [PATCH v2

Re: [PATCH v3 16/17] tools/xenstore: let check_store() check the accounting data

On 18.01.23 10:35, Julien Grall wrote: Hi Juergen, On 18/01/2023 06:23, Juergen Gross wrote: On 17.01.23 23:36, Julien Grall wrote: Hi Juergen, On 17/01/2023 09:11, Juergen Gross wrote: Today check_store() is only testing the correctness of the node tree. Add verification of the accounting

Re: [PATCH v3 16/17] tools/xenstore: let check_store() check the accounting data

Hi Juergen, On 18/01/2023 06:23, Juergen Gross wrote: On 17.01.23 23:36, Julien Grall wrote: Hi Juergen, On 17/01/2023 09:11, Juergen Gross wrote: Today check_store() is only testing the correctness of the node tree. Add verification of the accounting data (number of nodes)  and correct

Re: [PATCH v3 13/17] tools/xenstore: switch hashtable to use the talloc framework

Hi Juergen, On 17/01/2023 09:11, Juergen Gross wrote: Instead of using malloc() and friends, let the hashtable implementation use the talloc framework. This is more consistent with the rest of xenstored and it allows to track memory usage via "xenstore-control memreport". Signed-off-by:

Re: [PATCH v3 12/17] tools/xenstore: don't let hashtable_remove() return the removed value

On 18/01/2023 06:17, Juergen Gross wrote: On 17.01.23 23:03, Julien Grall wrote: Hi Juergen, On 17/01/2023 09:11, Juergen Gross wrote: Letting hashtable_remove() return the value of the removed element is not used anywhere in Xenstore, and it conflicts with a hashtable created specifying

Re: [PATCH RFC 05/10] x86: update GADDR based secondary time area

On 17.01.2023 21:31, Andrew Cooper wrote: > On 19/10/2022 8:41 am, Jan Beulich wrote: >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -1462,12 +1462,34 @@ static void __update_vcpu_system_time(st >> v->arch.pv.pending_system_time = _u; >> } >> >> +static void

Re: [XEN PATCH] Create a Kconfig option to set preferred reboot method

On 18/01/2023 07:15, Jan Beulich wrote: > On 17.01.2023 20:28, Per Bilse wrote: >> On 17/01/2023 15:55, Jan Beulich wrote: >>> On 16.01.2023 18:21, Per Bilse wrote: + config REBOOT_METHOD_XEN + bool "xen" + help + Use Xen SCHEDOP hypercall

Re: [XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

Hi Ayan, On 17/01/2023 17:43, Ayan Kumar Halder wrote: We have introduced a new config option to support 32 bit physical address. By default, it is disabled. ARM_PA_32 cannot be enabled on ARM_64 as the memory management unit works on 48bit physical addresses. I don't understand the "cannot"

Re: [PATCH RFC 03/10] domain: GADDR based shared guest area registration alternative - teardown

On 17.01.2023 22:17, Andrew Cooper wrote: > On 19/10/2022 8:40 am, Jan Beulich wrote: >> In preparation of the introduction of new vCPU operations allowing to >> register the respective areas (one of the two is x86-specific) by >> guest-physical address, add the necessary domain cleanup hooks. >

Re: [XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

On 17.01.2023 18:43, Ayan Kumar Halder wrote: > --- a/xen/arch/arm/include/asm/types.h > +++ b/xen/arch/arm/include/asm/types.h > @@ -37,9 +37,16 @@ typedef signed long long s64; > typedef unsigned long long u64; > typedef u32 vaddr_t; > #define PRIvaddr PRIx32 > +#if defined(CONFIG_ARM_PA_32)

Re: [XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

On 17.01.2023 18:43, Ayan Kumar Halder wrote: > One should now be able to use 'paddr_t' to represent address and size. > Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t. > > Signed-off-by: Ayan Kumar Halder > --- > > Changes from - > > v1 - 1. Rebased the patch. > >

Re: [PATCH 2/2] xen/cppcheck: add parameter to skip given MISRA rules

> On 6 Jan 2023, at 10:41, Luca Fancellu wrote: > > Add parameter to skip the passed MISRA rules during the cppcheck > analysis, the rules are specified as a list of comma separated > rules with the MISRA number notation (e.g. 1.1,1.3,...). > > Modify convert_misra_doc.py script to take an

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

On 17.01.2023 18:21, Andrew Cooper wrote: > On 16/01/2023 6:10 pm, Anthony PERARD wrote: >> +elif re.match(r'^[a-zA-Z_]', token): > >[...] > > All of this said, where is 0-9 in the token regex?  Have we just got > extremely lucky with having no embedded digits in identifiers thus far?