[PATCH] MAINTAINERS: remove myself from various positions
I have not been active in the Xen community for some time. Update the MAINTAINERS file to reflect reality. Signed-off-by: Wei Liu --- It has been a pleasure working with all of you. I'm sure we will cross paths in the future. Seabios is in need for a new owner. For now I left my name there. --- MAINTAINERS | 8 1 file changed, 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b2cc3cc3921b..f003085ad175 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -387,7 +387,6 @@ F: xen/arch/x86/machine_kexec.c F: xen/arch/x86/x86_64/kexec_reloc.S LIBS -M: Wei Liu M: Anthony PERARD R: Juergen Gross S: Supported @@ -422,7 +421,6 @@ F: xen/test/livepatch/* MINI-OS M: Samuel Thibault M: Juergen Gross -R: Wei Liu S: Supported L: minios-de...@lists.xenproject.org T: git https://xenbits.xenproject.org/git-http/mini-os.git @@ -436,7 +434,6 @@ F: tools/ocaml/ OVMF UPSTREAM M: Anthony PERARD -M: Wei Liu S: Supported T: git https://xenbits.xenproject.org/git-http/ovmf.git @@ -521,7 +518,6 @@ F: xen/arch/arm/include/asm/tee F: xen/arch/arm/tee/ TOOLSTACK -M: Wei Liu M: Anthony PERARD S: Supported F: autogen.sh @@ -583,7 +579,6 @@ X86 ARCHITECTURE M: Jan Beulich M: Andrew Cooper M: Roger Pau Monné -R: Wei Liu S: Supported L: xen-devel@lists.xenproject.org F: xen/arch/x86/ @@ -626,7 +621,6 @@ F: xen/arch/x86/mm/shadow/ X86 VIRIDIAN ENLIGHTENMENTS M: Paul Durrant -M: Wei Liu S: Supported F: xen/arch/x86/guest/hyperv/ F: xen/arch/x86/hvm/viridian/ @@ -636,7 +630,6 @@ F: xen/arch/x86/include/asm/guest/hyperv-tlfs.h F: xen/arch/x86/include/asm/hvm/viridian.h XENSTORE -M: Wei Liu M: Juergen Gross R: Julien Grall S: Supported @@ -682,7 +675,6 @@ M: George Dunlap M: Jan Beulich M: Julien Grall M: Stefano Stabellini -M: Wei Liu L: xen-devel@lists.xenproject.org S: Supported F: * -- 2.43.0
Re: [PATCH] xen-netback: use default TX queue size for vifs
On Thu, Oct 05, 2023 at 04:08:31PM +0200, Roger Pau Monne wrote:
> Do not set netback interfaces (vifs) default TX queue size to the ring size.
> The TX queue size is not related to the ring size, and using the ring size
> (32)
> as the queue size can lead to packet drops. Note the TX side of the vif
> interface in the netback domain is the one receiving packets to be injected
> to the guest.
>
> Do not explicitly set the TX queue length to any value when creating the
> interface, and instead use the system default. Note that the queue length can
> also be adjusted at runtime.
>
> Fixes: f942dc2552b8 ('xen network backend driver')
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
Re: [PATCH 14/15] hyper-v/azure: Remove now superfluous sentinel element from ctl_table array
Please change the prefix to "Drivers: hv:" in the subject line in the
two patches.
On Thu, Sep 28, 2023 at 03:21:39PM +0200, Joel Granados via B4 Relay wrote:
> From: Joel Granados
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which
> will reduce the overall build time size of the kernel and run time
> memory bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bombadil.infradead.org/)
>
> Remove sentinel from hv_ctl_table
>
> Signed-off-by: Joel Granados
> ---
> drivers/hv/hv_common.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index ccad7bca3fd3..bc7d678030aa 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -147,8 +147,7 @@ static struct ctl_table hv_ctl_table[] = {
> .proc_handler = proc_dointvec_minmax,
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE
> - },
> - {}
> + }
Please keep the comma at the end.
> };
>
> static int hv_die_panic_notify_crash(struct notifier_block *self,
>
> --
> 2.30.2
>
Re: [PATCH] xen/netback: Pass (void *) to virt_to_page()
On Wed, May 24, 2023 at 10:11:47PM -0700, Jakub Kicinski wrote: > On Tue, 23 May 2023 16:03:42 +0200 Linus Walleij wrote: > > virt_to_page() takes a virtual address as argument but > > the driver passes an unsigned long, which works because > > the target platform(s) uses polymorphic macros to calculate > > the page. > > > > Since many architectures implement virt_to_pfn() as > > a macro, this function becomes polymorphic and accepts both a > > (unsigned long) and a (void *). > > > > Fix this up by an explicit (void *) cast. > > Paul, Wei, looks like netdev may be the usual path for this patch > to flow thru, although I'm never 100% sure with Xen. Yes. Netdev is the right path. Thanks, Wei.
Re: [PATCH] xen/netback: Pass (void *) to virt_to_page()
On Tue, May 23, 2023 at 04:03:42PM +0200, Linus Walleij wrote: > virt_to_page() takes a virtual address as argument but > the driver passes an unsigned long, which works because > the target platform(s) uses polymorphic macros to calculate > the page. > > Since many architectures implement virt_to_pfn() as > a macro, this function becomes polymorphic and accepts both a > (unsigned long) and a (void *). > > Fix this up by an explicit (void *) cast. > > Cc: Wei Liu > Cc: Paul Durrant > Cc: xen-devel@lists.xenproject.org > Cc: net...@vger.kernel.org > Signed-off-by: Linus Walleij Acked-by: Wei Liu
Re: [PATCH v1 6/9] KVM: x86: Add Heki hypervisor support
On Fri, May 05, 2023 at 05:20:43PM +0200, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> Each supported hypervisor in x86 implements a struct x86_hyper_init to
> define the init functions for the hypervisor. Define a new init_heki()
> entry point in struct x86_hyper_init. Hypervisors that support Heki
> must define this init_heki() function. Call init_heki() of the chosen
> hypervisor in init_hypervisor_platform().
>
> Create a heki_hypervisor structure that each hypervisor can fill
> with its data and functions. This will allow the Heki feature to work
> in a hypervisor agnostic way.
>
> Declare and initialize a "heki_hypervisor" structure for KVM so KVM can
> support Heki. Define the init_heki() function for KVM. In init_heki(),
> set the hypervisor field in the generic "heki" structure to the KVM
> "heki_hypervisor". After this point, generic Heki code can access the
> KVM Heki data and functions.
>
[...]
> +static void kvm_init_heki(void)
> +{
> + long err;
> +
> + if (!kvm_para_available())
> + /* Cannot make KVM hypercalls. */
> + return;
> +
> + err = kvm_hypercall3(KVM_HC_LOCK_MEM_PAGE_RANGES, -1, -1, -1);
Why not do a proper version check or capability check here? If the ABI
or supported features ever change then we have something to rely on?
Thanks,
Wei.
Re: [PATCH v1 5/9] KVM: x86: Add new hypercall to lock control registers
On Fri, May 05, 2023 at 05:20:42PM +0200, Mickaël Salaün wrote:
> This enables guests to lock their CR0 and CR4 registers with a subset of
> X86_CR0_WP, X86_CR4_SMEP, X86_CR4_SMAP, X86_CR4_UMIP, X86_CR4_FSGSBASE
> and X86_CR4_CET flags.
>
> The new KVM_HC_LOCK_CR_UPDATE hypercall takes two arguments. The first
> is to identify the control register, and the second is a bit mask to
> pin (i.e. mark as read-only).
>
> These register flags should already be pinned by Linux guests, but once
> compromised, this self-protection mechanism could be disabled, which is
> not the case with this dedicated hypercall.
>
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: H. Peter Anvin
> Cc: Ingo Molnar
> Cc: Kees Cook
> Cc: Madhavan T. Venkataraman
> Cc: Paolo Bonzini
> Cc: Sean Christopherson
> Cc: Thomas Gleixner
> Cc: Vitaly Kuznetsov
> Cc: Wanpeng Li
> Signed-off-by: Mickaël Salaün
> Link: https://lore.kernel.org/r/20230505152046.6575-6-...@digikod.net
[...]
> hw_cr4 = (cr4_read_shadow() & X86_CR4_MCE) | (cr4 & ~X86_CR4_MCE);
> if (is_unrestricted_guest(vcpu))
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ffab64d08de3..a529455359ac 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7927,11 +7927,77 @@ static unsigned long emulator_get_cr(struct
> x86_emulate_ctxt *ctxt, int cr)
> return value;
> }
>
> +#ifdef CONFIG_HEKI
> +
> +extern unsigned long cr4_pinned_mask;
> +
Can this be moved to a header file?
> +static int heki_lock_cr(struct kvm *const kvm, const unsigned long cr,
> + unsigned long pin)
> +{
> + if (!pin)
> + return -KVM_EINVAL;
> +
> + switch (cr) {
> + case 0:
> + /* Cf. arch/x86/kernel/cpu/common.c */
> + if (!(pin & X86_CR0_WP))
> + return -KVM_EINVAL;
> +
> + if ((read_cr0() & pin) != pin)
> + return -KVM_EINVAL;
> +
> + atomic_long_or(pin, >heki_pinned_cr0);
> + return 0;
> + case 4:
> + /* Checks for irrelevant bits. */
> + if ((pin & cr4_pinned_mask) != pin)
> + return -KVM_EINVAL;
> +
It is enforcing the host mask on the guest, right? If the guest's set is a
super set of the host's then it will get rejected.
> + /* Ignores bits not present in host. */
> + pin &= __read_cr4();
> + atomic_long_or(pin, >heki_pinned_cr4);
> + return 0;
> + }
> + return -KVM_EINVAL;
> +}
> +
> +int heki_check_cr(const struct kvm *const kvm, const unsigned long cr,
> + const unsigned long val)
> +{
> + unsigned long pinned;
> +
> + switch (cr) {
> + case 0:
> + pinned = atomic_long_read(>heki_pinned_cr0);
> + if ((val & pinned) != pinned) {
> + pr_warn_ratelimited(
> + "heki-kvm: Blocked CR0 update: 0x%lx\n", val);
I think if the message contains the VM and VCPU identifier it will
become more useful.
Thanks,
Wei.
Re: [PATCH v1 3/9] virt: Implement Heki common code
On Fri, May 05, 2023 at 05:20:40PM +0200, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> Hypervisor Enforced Kernel Integrity (Heki) is a feature that will use
> the hypervisor to enhance guest virtual machine security.
>
> Configuration
> =
>
> Define the config variables for the feature. This feature depends on
> support from the architecture as well as the hypervisor.
>
> Enabling HEKI
> =
>
> Define a kernel command line parameter "heki" to turn the feature on or
> off. By default, Heki is on.
For such a newfangled feature can we have it off by default? Especially
when there are unsolved issues around dynamically loaded code.
>
[...]
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3604074a878b..5cf5a7a97811 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -297,6 +297,7 @@ config X86
> select FUNCTION_ALIGNMENT_4B
> imply IMA_SECURE_AND_OR_TRUSTED_BOOTif EFI
> select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> + select ARCH_SUPPORTS_HEKI if X86_64
Why is there a restriction on X86_64?
>
> config INSTRUCTION_DECODER
> def_bool y
> diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
> index a6e8373a5170..42ef1e33b8a5 100644
> --- a/arch/x86/include/asm/sections.h
> +++ b/arch/x86/include/asm/sections.h
[...]
>
> +#ifdef CONFIG_HEKI
> +
> +/*
> + * Gather all of the statically defined sections so heki_late_init() can
> + * protect these sections in the host page table.
> + *
> + * The sections are defined under "SECTIONS" in vmlinux.lds.S
> + * Keep this array in sync with SECTIONS.
> + */
This seems a bit fragile, because it requires constant attention from
people who care about this functionality. Can this table be
automatically generated?
Thanks,
Wei.
> +struct heki_va_range __initdata heki_va_ranges[] = {
> + {
> + .va_start = _stext,
> + .va_end = _etext,
> + .attributes = HEKI_ATTR_MEM_NOWRITE | HEKI_ATTR_MEM_EXEC,
> + },
> + {
> + .va_start = __start_rodata,
> + .va_end = __end_rodata,
> + .attributes = HEKI_ATTR_MEM_NOWRITE,
> + },
> +#ifdef CONFIG_UNWINDER_ORC
> + {
> + .va_start = __start_orc_unwind_ip,
> + .va_end = __stop_orc_unwind_ip,
> + .attributes = HEKI_ATTR_MEM_NOWRITE,
> + },
> + {
> + .va_start = __start_orc_unwind,
> + .va_end = __stop_orc_unwind,
> + .attributes = HEKI_ATTR_MEM_NOWRITE,
> + },
> + {
> + .va_start = orc_lookup,
> + .va_end = orc_lookup_end,
> + .attributes = HEKI_ATTR_MEM_NOWRITE,
> + },
> +#endif /* CONFIG_UNWINDER_ORC */
> +};
> +
Re: [PATCH 3/7] hv: simplify sysctl registration
On Thu, Mar 02, 2023 at 12:46:08PM -0800, Luis Chamberlain wrote: > register_sysctl_table() is a deprecated compatibility wrapper. > register_sysctl() can do the directory creation for you so just use > that. > > Signed-off-by: Luis Chamberlain Reviewed-by: Wei Liu
Re: [PATCH 1/6] hyperv: Make remove callback of hyperv driver void returned
On Mon, Dec 05, 2022 at 11:36:39PM +0800, Dawei Li wrote:
> Since commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.
>
> This change is for hyperv bus based drivers.
>
> Signed-off-by: Dawei Li
[...]
> -static int netvsc_remove(struct hv_device *dev)
> +static void netvsc_remove(struct hv_device *dev)
> {
> struct net_device_context *ndev_ctx;
> struct net_device *vf_netdev, *net;
> @@ -2603,7 +2603,6 @@ static int netvsc_remove(struct hv_device *dev)
> net = hv_get_drvdata(dev);
> if (net == NULL) {
> dev_err(>device, "No net device to remove\n");
> - return 0;
This is wrong. You are introducing a NULL pointer dereference.
> }
>
> ndev_ctx = netdev_priv(net);
> @@ -2637,7 +2636,6 @@ static int netvsc_remove(struct hv_device *dev)
>
> free_percpu(ndev_ctx->vf_stats);
> free_netdev(net);
> - return 0;
> }
>
> static int netvsc_suspend(struct hv_device *dev)
> diff --git a/drivers/pci/controller/pci-hyperv.c
> b/drivers/pci/controller/pci-hyperv.c
> index ba64284eaf9f..3a09de70d6ea 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -3756,7 +3756,7 @@ static int hv_pci_bus_exit(struct hv_device *hdev, bool
> keep_devs)
> *
> * Return: 0 on success, -errno on failure
> */
This comment is no longer needed in the new world.
But, are you sure you're modifying the correct piece of code?
hv_pci_remove is not a hook in the base bus type. It is used in struct
hv_driver.
The same comment applies to all other modifications.
Thanks,
Wei.
Re: [PATCH] xen-netback: use kstrdup instead of open-coding it
On Wed, Sep 21, 2022 at 02:16:17AM +, cgel@gmail.com wrote: > From: Minghao Chi > > use kstrdup instead of open-coding it. > > Reported-by: Zeal Robot > Signed-off-by: Minghao Chi Acked-by: Wei Liu
Re: [PATCH v2] x86/PCI: Prefer MMIO over PIO on VMware hypervisor
On Tue, Sep 06, 2022 at 12:38:37PM +0530, Ajay Kaher wrote: > During boot-time there are many PCI config reads, these could be performed > either using Port IO instructions (PIO) or memory mapped I/O (MMIO). > > PIO are less efficient than MMIO, they require twice as many PCI accesses > and PIO instructions are serializing. As a result, MMIO should be preferred > when possible over PIO. > > Virtual Machine test result using VMware hypervisor > 1 hundred thousand reads using raw_pci_read() took: > PIO: 12.809 seconds > MMIO: 8.517 seconds (~33.5% faster then PIO) > > Currently, when these reads are performed by a virtual machine, they all > cause a VM-exit, and therefore each one of them induces a considerable > overhead. > > This overhead can be further improved, by mapping MMIO region of virtual > machine to memory area that holds the values that the “emulated hardware” > is supposed to return. The memory region is mapped as "read-only” in the > NPT/EPT, so reads from these regions would be treated as regular memory > reads. Writes would still be trapped and emulated by the hypervisor. > > Virtual Machine test result with above changes in VMware hypervisor > 1 hundred thousand read using raw_pci_read() took: > PIO: 12.809 seconds > MMIO: 0.010 seconds > > This helps to reduce virtual machine PCI scan and initialization time by > ~65%. In our case it reduced to ~18 mSec from ~55 mSec. > > MMIO is also faster than PIO on bare-metal systems, but due to some bugs > with legacy hardware and the smaller gains on bare-metal, it seems prudent > not to change bare-metal behavior. > > Signed-off-by: Ajay Kaher The subject line should be fixed -- you're changing the behaviour for all hypervisors, not just VMWare. I almost skipped this because of the subject line. Thanks, Wei.
Re: [PATCH] xen/netback: fix incorrect usage of RING_HAS_UNCONSUMED_REQUESTS()
On Mon, May 30, 2022 at 01:34:59PM +0200, Juergen Gross wrote:
> Commit 6fac592cca60 ("xen: update ring.h") missed to fix one use case
> of RING_HAS_UNCONSUMED_REQUESTS().
>
> Reported-by: Jan Beulich
> Fixes: 6fac592cca60 ("xen: update ring.h")
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Re: [PATCH] xen/netback: do some code cleanup
On Mon, May 30, 2022 at 01:41:03PM +0200, Juergen Gross wrote: > Remove some unused macros and functions, make local functions static. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: Virtio on Xen with Rust
On Thu, Apr 14, 2022 at 02:36:12PM +0100, Alex Bennée wrote: > > Wei Liu writes: > > > On Thu, Apr 14, 2022 at 12:07:10PM +, Andrew Cooper wrote: > >> On 14/04/2022 12:45, Wei Liu wrote: > >> > Hi Viresh > >> > > >> > This is very cool. > >> > > >> > On Thu, Apr 14, 2022 at 02:53:58PM +0530, Viresh Kumar wrote: > >> >> +xen-devel > >> >> > >> >> On 14-04-22, 14:45, Viresh Kumar wrote: > >> >>> Hello, > >> >>> > >> >>> We verified our hypervisor-agnostic Rust based vhost-user backends > >> >>> with Qemu > >> >>> based setup earlier, and there was growing concern if they were truly > >> >>> hypervisor-agnostic. > >> >>> > >> >>> In order to prove that, we decided to give it a try with Xen, a type-1 > >> >>> bare-metal hypervisor. > >> >>> > >> >>> We are happy to announce that we were able to make progress on that > >> >>> front and > >> >>> have a working setup where we can test our existing Rust based > >> >>> backends, like > >> >>> I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > >> >>> > >> >>> Key components: > >> >>> -- > >> >>> > >> >>> - Xen: https://github.com/vireshk/xen > >> >>> > >> >>> Xen requires MMIO and device specific support in order to populate > >> >>> the > >> >>> required devices at the guest. This tree contains four patches on > >> >>> the top of > >> >>> mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > >> >>> > >> >>> - libxen-sys: https://github.com/vireshk/libxen-sys > >> >>> > >> >>> We currently depend on the userspace tools/libraries provided by > >> >>> Xen, like > >> >>> xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates > >> >>> provides Rust > >> >>> wrappers over those calls, generated automatically with help of > >> >>> bindgen > >> >>> utility in Rust, that allow us to use the installed Xen libraries. > >> >>> Though we > >> >>> plan to replace this with Rust based "oxerun" (find below) in longer > >> >>> run. > >> >>> > >> >>> - oxerun (WIP): > >> >>> https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > >> >>> > >> >>> This is Rust based implementations for Ioctl and hypercalls to Xen. > >> >>> This is WIP > >> >>> and should eventually replace "libxen-sys" crate entirely (which are > >> >>> C based > >> >>> implementation of the same). > >> >>> > >> > I'm curious to learn why there is a need to replace libxen-sys with the > >> > pure Rust implementation. Those libraries (xendevicemodel, xenevtchn, > >> > xenforeignmemory) are very stable and battle tested. Their interfaces > >> > are stable. > >> > >> Very easy. The library APIs are mess even if they are technically > >> stable, and violate various commonly-agreed rules of being a libary such > >> as not messing with stdout/stderr behind the applications back, and > >> everything gets more simple when you remove an unnecessary level of C > >> indirection. > > > > You don't have to use the stdio logger FWIW. I don't disagree things can > > be simpler though. > > Not directly related to this use case but the Rust API can also be > built to make direct HYP calls which will be useful for building Rust > based unikernels that need to interact with Xen. For example for a > dom0less system running a very minimal heartbeat/healthcheck monitor > written in pure rust. > I think this is a strong reason for not using existing C libraries. It would be nice if the APIs can work with no_std. > We would also like to explore unikernel virtio backends but I suspect > currently the rest of the rust-vmm virtio bits assume a degree of POSIX > like userspace to set things up. Indeed. Thanks, Wei. > > -- > Alex Bennée
Re: Virtio on Xen with Rust
On Thu, Apr 14, 2022 at 12:07:10PM +, Andrew Cooper wrote: > On 14/04/2022 12:45, Wei Liu wrote: > > Hi Viresh > > > > This is very cool. > > > > On Thu, Apr 14, 2022 at 02:53:58PM +0530, Viresh Kumar wrote: > >> +xen-devel > >> > >> On 14-04-22, 14:45, Viresh Kumar wrote: > >>> Hello, > >>> > >>> We verified our hypervisor-agnostic Rust based vhost-user backends with > >>> Qemu > >>> based setup earlier, and there was growing concern if they were truly > >>> hypervisor-agnostic. > >>> > >>> In order to prove that, we decided to give it a try with Xen, a type-1 > >>> bare-metal hypervisor. > >>> > >>> We are happy to announce that we were able to make progress on that front > >>> and > >>> have a working setup where we can test our existing Rust based backends, > >>> like > >>> I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > >>> > >>> Key components: > >>> -- > >>> > >>> - Xen: https://github.com/vireshk/xen > >>> > >>> Xen requires MMIO and device specific support in order to populate the > >>> required devices at the guest. This tree contains four patches on the > >>> top of > >>> mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > >>> > >>> - libxen-sys: https://github.com/vireshk/libxen-sys > >>> > >>> We currently depend on the userspace tools/libraries provided by Xen, > >>> like > >>> xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides > >>> Rust > >>> wrappers over those calls, generated automatically with help of bindgen > >>> utility in Rust, that allow us to use the installed Xen libraries. > >>> Though we > >>> plan to replace this with Rust based "oxerun" (find below) in longer > >>> run. > >>> > >>> - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > >>> > >>> This is Rust based implementations for Ioctl and hypercalls to Xen. > >>> This is WIP > >>> and should eventually replace "libxen-sys" crate entirely (which are C > >>> based > >>> implementation of the same). > >>> > > I'm curious to learn why there is a need to replace libxen-sys with the > > pure Rust implementation. Those libraries (xendevicemodel, xenevtchn, > > xenforeignmemory) are very stable and battle tested. Their interfaces > > are stable. > > Very easy. The library APIs are mess even if they are technically > stable, and violate various commonly-agreed rules of being a libary such > as not messing with stdout/stderr behind the applications back, and > everything gets more simple when you remove an unnecessary level of C > indirection. You don't have to use the stdio logger FWIW. I don't disagree things can be simpler though. Wei. > > ~Andrew
Re: Virtio on Xen with Rust
Hi Viresh This is very cool. On Thu, Apr 14, 2022 at 02:53:58PM +0530, Viresh Kumar wrote: > +xen-devel > > On 14-04-22, 14:45, Viresh Kumar wrote: > > Hello, > > > > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu > > based setup earlier, and there was growing concern if they were truly > > hypervisor-agnostic. > > > > In order to prove that, we decided to give it a try with Xen, a type-1 > > bare-metal hypervisor. > > > > We are happy to announce that we were able to make progress on that front > > and > > have a working setup where we can test our existing Rust based backends, > > like > > I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > > > > Key components: > > -- > > > > - Xen: https://github.com/vireshk/xen > > > > Xen requires MMIO and device specific support in order to populate the > > required devices at the guest. This tree contains four patches on the top > > of > > mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > > > > - libxen-sys: https://github.com/vireshk/libxen-sys > > > > We currently depend on the userspace tools/libraries provided by Xen, like > > xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides > > Rust > > wrappers over those calls, generated automatically with help of bindgen > > utility in Rust, that allow us to use the installed Xen libraries. Though > > we > > plan to replace this with Rust based "oxerun" (find below) in longer run. > > > > - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > > > > This is Rust based implementations for Ioctl and hypercalls to Xen. This > > is WIP > > and should eventually replace "libxen-sys" crate entirely (which are C > > based > > implementation of the same). > > I'm curious to learn why there is a need to replace libxen-sys with the pure Rust implementation. Those libraries (xendevicemodel, xenevtchn, xenforeignmemory) are very stable and battle tested. Their interfaces are stable. Thanks, Wei.
Re: [PATCH] libxl: force netback to wait for hotplug execution before connecting
On Mon, Jan 24, 2022 at 05:02:48PM +0100, Roger Pau Monne wrote: > By writing an empty "hotplug-status" xenstore node in the backend path > libxl can force Linux netback to wait for hotplug script execution > before proceeding to the 'connected' state. > > This is required so that netback doesn't skip state 2 (InitWait) and > thus blocks libxl waiting for such state in order to launch the > hotplug script (see libxl__wait_device_connection). > > Reported-by: James Dingwall > Signed-off-by: Roger Pau Monné > Tested-by: James Dingwall Reviewed-by: Wei Liu
Re: [PATCH] x86/APIC: mark wait_tick_pvh() __init
On Mon, Jan 17, 2022 at 11:34:20AM +0100, Jan Beulich wrote:
> It should have been that way right from its introduction by 02e0de011555
> ("x86: APIC timer calibration when running as a guest").
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
>
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1190,7 +1190,7 @@ static void __init check_deadline_errata
> "please update microcode to version %#x (or later)\n", rev);
> }
>
> -static void wait_tick_pvh(void)
> +static void __init wait_tick_pvh(void)
> {
> u64 lapse_ns = 10ULL / HZ;
> s_time_t start, curr_time;
>
[PATCH] Config.mk: update seabios to 1.15.0
Signed-off-by: Wei Liu --- Config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Config.mk b/Config.mk index 1c1998a5a8e0..38e88b2927d2 100644 --- a/Config.mk +++ b/Config.mk @@ -233,7 +233,7 @@ OVMF_UPSTREAM_REVISION ?= 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5 QEMU_UPSTREAM_REVISION ?= master MINIOS_UPSTREAM_REVISION ?= 9f09744aa3e5982a083ecf8e9cd2123f477081f9 -SEABIOS_UPSTREAM_REVISION ?= rel-1.14.0 +SEABIOS_UPSTREAM_REVISION ?= rel-1.15.0 ETHERBOOT_NICS ?= rtl8139 8086100e -- 2.30.2
Re: SeaBIOS 1.15.0
On Tue, Jan 11, 2022 at 09:37:56AM +0100, Jan Beulich wrote: > Wei, > > iirc it was you who has been looking after our SeaBIOS use. Seeing that > 1.15.0 was tagged, should we update the version we use by default? (I > would have asked on irc, but I didn't see you there.) > Yes, we should. I will find some time to update it this week. Sorry for the delay. Wei. > Jan >
Re: [PATCH V3 3/5] hyperv/IOMMU: Enable swiotlb bounce buffer for Isolation VM
On Wed, Dec 01, 2021 at 11:02:54AM -0500, Tianyu Lan wrote: [...] > diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c > index 46df59aeaa06..30fd0600b008 100644 > --- a/arch/x86/xen/pci-swiotlb-xen.c > +++ b/arch/x86/xen/pci-swiotlb-xen.c > @@ -4,6 +4,7 @@ > > #include > #include > +#include > #include > > #include > @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void) > EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late); > > IOMMU_INIT_FINISH(pci_xen_swiotlb_detect, > - NULL, > + hyperv_swiotlb_detect, It is not immediately obvious why this is needed just by reading the code. Please consider copying some of the text in the commit message to a comment here. Thanks, Wei.
Re: [PATCH V3 2/5] x86/hyper-v: Add hyperv Isolation VM check in the cc_platform_has()
On Wed, Dec 01, 2021 at 11:02:53AM -0500, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides Isolation VM which has memory encrypt support. Add
> hyperv_cc_platform_has() and return true for check of GUEST_MEM_ENCRYPT
> attribute.
>
> Signed-off-by: Tianyu Lan
> ---
> arch/x86/kernel/cc_platform.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/x86/kernel/cc_platform.c b/arch/x86/kernel/cc_platform.c
> index 03bb2f343ddb..f3bb0431f5c5 100644
> --- a/arch/x86/kernel/cc_platform.c
> +++ b/arch/x86/kernel/cc_platform.c
> @@ -11,6 +11,7 @@
> #include
> #include
>
> +#include
> #include
>
> static bool __maybe_unused intel_cc_platform_has(enum cc_attr attr)
> @@ -58,9 +59,23 @@ static bool amd_cc_platform_has(enum cc_attr attr)
> #endif
> }
>
> +static bool hyperv_cc_platform_has(enum cc_attr attr)
> +{
> +#ifdef CONFIG_HYPERV
> + if (attr == CC_ATTR_GUEST_MEM_ENCRYPT)
> + return true;
> + else
> + return false;
This can be simplified as
return attr == CC_ATTR_GUEST_MEM_ENCRYPT;
Wei.
Re: [patch 11/22] x86/hyperv: Refactor hv_msi_domain_free_irqs()
On Sat, Nov 27, 2021 at 02:18:51AM +0100, Thomas Gleixner wrote: > No point in looking up things over and over. Just look up the associated > irq data and work from there. > > No functional change. > > Signed-off-by: Thomas Gleixner Acked-by: Wei Liu
Re: [PATCH net-next v2 01/12] net: xen: use eth_hw_addr_set()
On Thu, Oct 21, 2021 at 06:12:03AM -0700, Jakub Kicinski wrote:
> Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
> of VLANs...") introduced a rbtree for faster Ethernet address look
> up. To maintain netdev->dev_addr in this tree we need to make all
> the writes to it got through appropriate helpers.
>
> Signed-off-by: Jakub Kicinski
Acked-by: Wei Liu
Re: [PATCH V3 03/13] x86/HV: Add new hvcall guest address host visibility support
On Mon, Aug 09, 2021 at 01:56:07PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support to mark
> memory visible to host. Call it inside set_memory_decrypted
> /encrypted(). Add HYPERVISOR feature check in the
> hv_is_isolation_supported() to optimize in non-virtualization
> environment.
>
> Signed-off-by: Tianyu Lan
> ---
> Change since v2:
>* Rework __set_memory_enc_dec() and call Hyper-V and AMD function
> according to platform check.
>
> Change since v1:
>* Use new staic call x86_set_memory_enc to avoid add Hyper-V
> specific check in the set_memory code.
> ---
> arch/x86/hyperv/Makefile | 2 +-
> arch/x86/hyperv/hv_init.c | 6 ++
> arch/x86/hyperv/ivm.c | 114 +
> arch/x86/include/asm/hyperv-tlfs.h | 20 +
> arch/x86/include/asm/mshyperv.h| 4 +-
> arch/x86/mm/pat/set_memory.c | 19 +++--
> include/asm-generic/hyperv-tlfs.h | 1 +
> include/asm-generic/mshyperv.h | 1 +
> 8 files changed, 160 insertions(+), 7 deletions(-)
> create mode 100644 arch/x86/hyperv/ivm.c
>
> diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
> index 48e2c51464e8..5d2de10809ae 100644
> --- a/arch/x86/hyperv/Makefile
> +++ b/arch/x86/hyperv/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -obj-y:= hv_init.o mmu.o nested.o irqdomain.o
> +obj-y:= hv_init.o mmu.o nested.o irqdomain.o ivm.o
> obj-$(CONFIG_X86_64) += hv_apic.o hv_proc.o
>
> ifdef CONFIG_X86_64
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 0bb4d9ca7a55..b3683083208a 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -607,6 +607,12 @@ EXPORT_SYMBOL_GPL(hv_get_isolation_type);
>
> bool hv_is_isolation_supported(void)
> {
> + if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> + return 0;
Nit: false instead of 0.
> +
> + if (!hypervisor_is_type(X86_HYPER_MS_HYPERV))
> + return 0;
> +
> return hv_get_isolation_type() != HV_ISOLATION_TYPE_NONE;
> }
>
[...]
> +int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
> +enum hv_mem_host_visibility visibility)
> +{
> + struct hv_gpa_range_for_visibility **input_pcpu, *input;
> + u16 pages_processed;
> + u64 hv_status;
> + unsigned long flags;
> +
> + /* no-op if partition isolation is not enabled */
> + if (!hv_is_isolation_supported())
> + return 0;
> +
> + if (count > HV_MAX_MODIFY_GPA_REP_COUNT) {
> + pr_err("Hyper-V: GPA count:%d exceeds supported:%lu\n", count,
> + HV_MAX_MODIFY_GPA_REP_COUNT);
> + return -EINVAL;
> + }
> +
> + local_irq_save(flags);
> + input_pcpu = (struct hv_gpa_range_for_visibility **)
> + this_cpu_ptr(hyperv_pcpu_input_arg);
> + input = *input_pcpu;
> + if (unlikely(!input)) {
> + local_irq_restore(flags);
> + return -EINVAL;
> + }
> +
> + input->partition_id = HV_PARTITION_ID_SELF;
> + input->host_visibility = visibility;
> + input->reserved0 = 0;
> + input->reserved1 = 0;
> + memcpy((void *)input->gpa_page_list, pfn, count * sizeof(*pfn));
> + hv_status = hv_do_rep_hypercall(
> + HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY, count,
> + 0, input, _processed);
> + local_irq_restore(flags);
> +
> + if (!(hv_status & HV_HYPERCALL_RESULT_MASK))
> + return 0;
> +
> + return hv_status & HV_HYPERCALL_RESULT_MASK;
Joseph introduced a few helper functions in 753ed9c95c37d. They will
make the code simpler.
Wei.
Re: [PATCH V3 01/13] x86/HV: Initialize GHCB page in Isolation VM
On Mon, Aug 09, 2021 at 01:56:05PM -0400, Tianyu Lan wrote:
[...]
> static int hv_cpu_init(unsigned int cpu)
> {
> union hv_vp_assist_msr_contents msr = { 0 };
> @@ -85,6 +111,8 @@ static int hv_cpu_init(unsigned int cpu)
> }
> }
>
> + hyperv_init_ghcb();
> +
Why is the return value not checked here? If that's not required, can
you leave a comment?
Wei.
Re: PING Re: [PATCH 00/14] Use const whether we point to literal strings (take 1)
On Mon, May 10, 2021 at 06:49:01PM +0100, Julien Grall wrote: > Hi, > > Ian, Wei, Anthony, can I get some feedbacks on the tools side? I think this is moving to the right direction so Acked-by: Wei Liu
Re: [PATCH v2 2/6] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table
On Wed, Apr 21, 2021 at 12:17:49PM +0200, Juergen Gross wrote: > On 21.04.21 12:13, Wei Liu wrote: > > On Mon, Apr 12, 2021 at 05:22:32PM +0200, Juergen Gross wrote: > > > The core of a pv linux guest produced via "xl dump-core" is not usable > > > as since kernel 4.14 only the linear p2m table is kept if Xen indicates > > > it is supporting that. Unfortunately xc_core_arch_map_p2m() is still > > > supporting the 3-level p2m tree only. > > > > > > Fix that by copying the functionality of map_p2m() from libxenguest to > > > libxenctrl. > > > > > > > So there are now two copies of the same logic? Is it possible to reduce > > it to only one? > > Yes. See the intro mail of the series. > > I wanted to fix the issue first, before doing the major cleanup work. Acked-by: Wei Liu
Re: [PATCH] automation: save xen config before building
On Wed, May 05, 2021 at 02:23:37PM +0200, Roger Pau Monné wrote: > On Wed, May 05, 2021 at 11:45:16AM +0000, Wei Liu wrote: > > It is reported that failed randconfig runs are missing the config file > > which makes debugging impossible. Fix this by moving the line that > > copies the config file before the build is executed. > > > > Signed-off-by: Wei Liu > > Acked-by: Roger Pau Monné A patchew run shows this indeed fixes the issue. I've pushed this to staging. Wei. > > Thanks!
Re: [XEN PATCH v2] xl: constify cmd_table entries
On Tue, May 04, 2021 at 05:14:36PM +0100, Anthony PERARD wrote: > Also constify cmdtable_len and make use of ARRAY_SIZE, which is > available in "xen-tools/libs.h". > > The entries in cmd_table don't need to be modified once xl is running. > > Signed-off-by: Anthony PERARD > Reviewed-by: Julien Grall Acked-by: Wei Liu
[PATCH] automation: save xen config before building
It is reported that failed randconfig runs are missing the config file
which makes debugging impossible. Fix this by moving the line that
copies the config file before the build is executed.
Signed-off-by: Wei Liu
---
automation/scripts/build | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/automation/scripts/build b/automation/scripts/build
index eaf70b11d1cb..46b6903d2922 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -16,6 +16,10 @@ else
make -j$(nproc) -C xen defconfig
fi
+# Save the config file before building because build failure causes the script
+# to exit early -- bash is invoked with -e.
+cp xen/.config xen-config
+
# arm32 only cross-compiles the hypervisor
if [[ "${XEN_TARGET_ARCH}" = "arm32" ]]; then
hypervisor_only="y"
@@ -59,7 +63,6 @@ else
fi
# Extract artifacts to avoid getting rewritten by customised builds
-cp xen/.config xen-config
mkdir binaries
if [[ "${XEN_TARGET_ARCH}" != "x86_32" ]]; then
cp xen/xen binaries/xen
--
2.30.2
Re: [PATCH RFCv2 12/15] xen/arm: add Persistent Map (PMAP) infrastructure
On Sun, Apr 25, 2021 at 09:13:15PM +0100, Julien Grall wrote: > From: Wei Liu > > The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We > pre-populate all the relevant page tables before the system is fully > set up. > > We will need it on Arm in order to rework the arm64 version of > xenheap_setup_mappings() as we may need to use pages allocated from > the boot allocator before they are effectively mapped. > > This infrastructure is not lock-protected therefore can only be used > before smpboot. After smpboot, map_domain_page() has to be used. > > This is based on the x86 version [1] that was originally implemented > by Wei Liu. > > Take the opportunity to switch the parameter attr from unsigned to > unsigned int. > > [1] > > > Signed-off-by: Wei Liu > Signed-off-by: Hongyan Xia > [julien: Adapted for Arm] > Signed-off-by: Julien Grall > > --- > Changes in v2: > - New patch > > Cc: Jan Beulich > Cc: Wei Liu > Cc: Andrew Cooper > Cc: Roger Pau Monné > Cc: Hongian Xia > > This is mostly a copy of the PMAP infrastructure currently discussed > on x86. The only difference is how the page-tables are updated. > > I think we want to consider to provide a common infrastructure. But > I haven't done it yet to gather feedback on the overall series > first. +1. This infrastructure should be common code with arch hooks where appropriate. Wei.
Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones
On Wed, Apr 21, 2021 at 01:26:49PM +0200, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 10:22:39AM +0000, Wei Liu wrote: > > On Tue, Apr 13, 2021 at 04:01:33PM +0200, Roger Pau Monne wrote: > > > Introduce a helper to obtain a compatible cpu policy based on two > > > input cpu policies. Currently this is done by and'ing all CPUID leaves > > > and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA > > > bit or'ed. > > > > > > > I thought canonical source for compatibility was to be put into the > > hypervisor, thus all this functionality would be in the hypervisor. Am I > > misremembering? > > Andrew said something similar on v1, but I'm not able to figure how > this would be used by the hypervisor. > > It's my understating that the toolstack will attempt to generate a CPU > policy and forward it to the hypervisor, which will either accept or > reject it based on the capabilities of the system. I'm not sure I see > why we would need to give the hypervisor two policies in order to > generate a resulting compatible one - it should all be done by the > toolstack AFAICT. > > If there's a use case for this being in the hypervisor I'm happy to > add it there, but so far I haven't been able to come up with one > myself, and hence I don't see the need to make the code available. I have no opinion here. Just wanted to get on the same page. Thanks for the explanation. Wei. > > Thanks, Roger.
Re: [PATCH v4] tools: create libxensaverestore
On Thu, Apr 15, 2021 at 03:11:38PM +0200, Olaf Hering wrote: > Move all save/restore related code from libxenguest.so into a separate > library libxensaverestore.so. 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. > > According to size(1) the change is: >text data bss dec hex filename > 187183 4304 48 191535 2ec2f guest/libxenguest.so.4.15.0 > > 124106 3376 48 127530 1f22a guest/libxenguest.so.4.15.0 > 67841 1872 8 69721 11059 > saverestore/libxensaverestore.so.4.15.0 > > While touching the files anyway, take the opportunity to drop the > reduntant xg_sr_ filename prefix. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu
Re: [PATCH v3] tools: create libxensaverestore
On Tue, Apr 13, 2021 at 07:20:27PM +0200, Olaf Hering wrote: > Move all save/restore related code from libxenguest.so into a separate > library libxensaverestore.so. 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. Good idea. Please address Jan and Juergen's comment regarding the prefix. Wei.
Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones
On Tue, Apr 13, 2021 at 04:01:33PM +0200, Roger Pau Monne wrote: > Introduce a helper to obtain a compatible cpu policy based on two > input cpu policies. Currently this is done by and'ing all CPUID leaves > and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA > bit or'ed. > I thought canonical source for compatibility was to be put into the hypervisor, thus all this functionality would be in the hypervisor. Am I misremembering? Wei.
Re: [PATCH v2 6/6] tools/libs/guest: make some definitions private to libxenguest
On Mon, Apr 12, 2021 at 05:22:36PM +0200, Juergen Gross wrote: > There are some definitions which are used in libxenguest only now. > Move them from libxenctrl over to libxenguest. > > Remove an unused macro. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: [PATCH v2 5/6] tools/libs: move xc_core* from libxenctrl to libxenguest
On Mon, Apr 12, 2021 at 05:22:35PM +0200, Juergen Gross wrote: > The functionality in xc_core* should be part of libxenguest instead > of libxenctrl. Users are already either in libxenguest, or in xl. > There is one single exception: xc_core_arch_auto_translated_physmap() > is being used by xc_domain_memory_mapping(), which is used by qemu. > So leave the xc_core_arch_auto_translated_physmap() functionality in > libxenctrl. > > This will make it easier to merge common functionality of xc_core* > and xg_sr_save*. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: [PATCH v2 4/6] tools/libs: move xc_resume.c to libxenguest
On Mon, Apr 12, 2021 at 05:22:34PM +0200, Juergen Gross wrote: > The guest suspend functionality is already part of libxenguest. Move > the resume functionality from libxenctrl to libxenguest, too. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: [PATCH v2 3/6] tools/libs/ctrl: use common p2m mapping code in xc_domain_resume_any()
On Mon, Apr 12, 2021 at 05:22:33PM +0200, Juergen Gross wrote: > Instead of open coding the mapping of the p2m list use the already > existing xc_core_arch_map_p2m() call, especially as the current code > does not support guests with the linear p2m map. It should be noted > that this code is needed for colo/remus only. > > Switching to xc_core_arch_map_p2m() drops the need to bail out for > bitness of tool stack and guest differing. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu
Re: [PATCH v2 1/6] tools/libs/guest: fix max_pfn setting in map_p2m()
On Mon, Apr 12, 2021 at 05:22:31PM +0200, Juergen Gross wrote:
> When setting the highest pfn used in the guest, don't subtract 1 from
> the value read from the shared_info data. The value read already is
> the correct pfn.
>
> Fixes: 91e204d37f449 ("libxc: try to find last used pfn when migrating")
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Re: [PATCH v2 2/6] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table
On Mon, Apr 12, 2021 at 05:22:32PM +0200, Juergen Gross wrote: > The core of a pv linux guest produced via "xl dump-core" is not usable > as since kernel 4.14 only the linear p2m table is kept if Xen indicates > it is supporting that. Unfortunately xc_core_arch_map_p2m() is still > supporting the 3-level p2m tree only. > > Fix that by copying the functionality of map_p2m() from libxenguest to > libxenctrl. > So there are now two copies of the same logic? Is it possible to reduce it to only one? Wei.
Re: [PATCH] tools/libs/light: Remove unnecessary libxl_list_vm() call
On Mon, Apr 19, 2021 at 04:01:42PM +0300, Costin Lupu wrote:
> The removed lines were initially added by commit 314e64084d31, but the
> subsequent code which was using the nb_vm variable was later removed by
> commit 2ba368d13893, which makes these lines of code an overlooked
> reminiscence. Moreover, the call becomes very expensive when there is a
> considerable number of VMs (~1000 instances) running on the host.
>
Nice catch.
> Signed-off-by: Costin Lupu
Acked-by: Wei Liu
> ---
> tools/libs/light/libxl_create.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index 0c64268f66..43e9ba9c63 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -578,7 +578,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
> *d_config,
> uint32_t *domid, bool soft_reset)
> {
> libxl_ctx *ctx = libxl__gc_owner(gc);
> -int ret, rc, nb_vm;
> +int ret, rc;
> const char *dom_type;
> char *uuid_string;
> char *dom_path, *vm_path, *libxl_path;
> @@ -586,7 +586,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
> *d_config,
> struct xs_permissions rwperm[1];
> struct xs_permissions noperm[1];
> xs_transaction_t t = 0;
> -libxl_vminfo *vm_list;
>
> /* convenience aliases */
> libxl_domain_create_info *info = _config->c_info;
> @@ -869,14 +868,6 @@ retry_transaction:
> ARRAY_SIZE(rwperm));
> }
>
> -vm_list = libxl_list_vm(ctx, _vm);
> -if (!vm_list) {
> -LOGD(ERROR, *domid, "cannot get number of running guests");
> -rc = ERROR_FAIL;
> -goto out;
> -}
> -libxl_vminfo_list_free(vm_list, nb_vm);
> -
> xs_write(ctx->xsh, t, GCSPRINTF("%s/uuid", vm_path), uuid_string,
> strlen(uuid_string));
> xs_write(ctx->xsh, t, GCSPRINTF("%s/name", vm_path), info->name,
> strlen(info->name));
>
> --
> 2.20.1
>
Re: [PATCH] tools: Drop XGETTEXT from Tools.mk.in
On Fri, Apr 16, 2021 at 04:59:41PM +0100, Andrew Cooper wrote:
> This hunk was missing from the work to drop gettext as a build dependency.
>
> Fixes: e21a6a4f96 ("tools: Drop gettext as a build dependency")
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
> ---
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Julien Grall
> CC: Juergen Gross
> ---
> config/Tools.mk.in | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index d47936686b..934d899967 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -12,7 +12,6 @@ PYTHON := @PYTHON@
> PYTHON_PATH := @PYTHONPATH@
> PY_NOOPT_CFLAGS := @PY_NOOPT_CFLAGS@
> PERL:= @PERL@
> -XGETTTEXT := @XGETTEXT@
> AS86:= @AS86@
> LD86:= @LD86@
> BCC := @BCC@
> --
> 2.11.0
>
Re: [PATCH] CI: Drop TravisCI
On Wed, Apr 21, 2021 at 10:27:05AM +0100, Andrew Cooper wrote: > Travis-ci.org is shutting down shortly. The arm cross-compile testing has > been broken for a long time now, and all testing has now been superseded by > our Gitlab infrastructure. > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu I guess this also needs backporting?
Re: [PATCH] xen/evtchn: Change irq_info lock to raw_spinlock_t
On Tue, Apr 06, 2021 at 11:51:04AM +0100, Luca Fancellu wrote:
> Unmask operation must be called with interrupt disabled,
> on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
> don't disable/enable interrupts, so use raw_* implementation
> and change lock variable in struct irq_info from spinlock_t
> to raw_spinlock_t
>
> Cc: sta...@vger.kernel.org
> Fixes: 25da4618af24 ("xen/events: don't unmask an event channel
> when an eoi is pending")
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Wei Liu
Re: [PATCH v2 3/3] x86: avoid building COMPAT code when !HVM && !PV32
On Tue, Apr 06, 2021 at 04:02:08PM +0200, Jan Beulich wrote: > It was probably a mistake to, over time, drop various CONFIG_COMPAT > conditionals from x86-specific code, as we now have a build > configuration again where we'd prefer this to be unset. Arrange for > CONFIG_COMPAT to actually be off in this case, dealing with fallout. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu
Re: [PATCH v2 2/3] x86: slim down hypercall handling when !PV32
On Tue, Apr 06, 2021 at 04:01:41PM +0200, Jan Beulich wrote: > In such a build various of the compat handlers aren't needed. Don't > reference them from the hypercall table, and compile out those which > aren't needed for HVM. Also compile out switch_compat(), which has no > purpose in such a build. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu
Re: [PATCH v2 1/3] x86: don't build unused entry code when !PV32
On Tue, Apr 06, 2021 at 04:01:22PM +0200, Jan Beulich wrote: > Except for the initial part of cstar_enter compat/entry.S is all dead > code in this case. Further, along the lines of the PV conditionals we > already have in entry.S, make code PV32-conditional there too (to a > fair part because this code actually references compat/entry.S). > > This has the side effect of moving the tail part (now at compat_syscall) > of the code out of .text.entry (in line with e.g. compat_sysenter). > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu
Re: [PATCH v2 for-4.14] tools: Fix pkg-config file for libxenstore
On Mon, Mar 22, 2021 at 04:38:47PM +, Andrew Cooper wrote:
> There are no dependenices on evtchn, ctrl or gnttab.
>
> Fixes: 1b008e99 ("tools: provide pkg-config file for libxenstore")
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
Re: [PATCH] automation: remove allow_failure from Alpine Linux jobs
On Fri, Mar 12, 2021 at 01:05:26PM -0800, Stefano Stabellini wrote: > Now that the Alpine Linux build jobs complete successfully on staging we > can remove the "allow_failure: true" tag. > > Signed-off-by: Stefano Stabellini Acked-by: Wei Liu
Re: [PATCH] automation: add arm32 cross-build tests for Xen
On Fri, Feb 12, 2021 at 05:38:13PM -0800, Stefano Stabellini wrote:
> Add a debian build container with cross-gcc for arm32 installed.
> Add build jobs to cross-compile Xen-only for arm32.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
Cc Ian.
The risk is small: Gitlab CI doesn't gate pushes to Xen, but it is
rather beneficial to have arm32 builds for Xen.
> ---
> .../debian/unstable-arm32-gcc.dockerfile | 24 +
> automation/gitlab-ci/build.yaml | 50 +++
> automation/scripts/build | 9
> 3 files changed, 83 insertions(+)
> create mode 100644 automation/build/debian/unstable-arm32-gcc.dockerfile
>
> diff --git a/automation/build/debian/unstable-arm32-gcc.dockerfile
> b/automation/build/debian/unstable-arm32-gcc.dockerfile
> new file mode 100644
> index 00..b41a57f197
> --- /dev/null
> +++ b/automation/build/debian/unstable-arm32-gcc.dockerfile
> @@ -0,0 +1,24 @@
> +FROM debian:unstable
> +LABEL maintainer.name="The Xen Project" \
> + maintainer.email="xen-devel@lists.xenproject.org"
> +
> +ENV DEBIAN_FRONTEND=noninteractive
> +ENV USER root
> +ENV CROSS_COMPILE /usr/bin/arm-linux-gnueabihf-
> +
> +RUN mkdir /build
> +WORKDIR /build
> +
> +# build depends
> +RUN apt-get update && \
> +apt-get --quiet --yes install \
> +build-essential \
> +flex \
> +bison \
> +git \
> +gcc-arm-linux-gnueabihf \
> +&& \
> +apt-get autoremove -y && \
> +apt-get clean && \
> +rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
> +
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index d00b8a5123..22114662f2 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -117,6 +117,33 @@
>variables:
> <<: *clang
>
> +.arm32-cross-build-tmpl:
> + <<: *build
> + variables:
> +XEN_TARGET_ARCH: arm32
> + tags:
> +- x86_64
> +
> +.arm32-cross-build:
> + extends: .arm32-cross-build-tmpl
> + variables:
> +debug: n
> +
> +.arm32-cross-build-debug:
> + extends: .arm32-cross-build-tmpl
> + variables:
> +debug: y
> +
> +.gcc-arm32-cross-build:
> + extends: .arm32-cross-build
> + variables:
> +<<: *gcc
> +
> +.gcc-arm32-cross-build-debug:
> + extends: .arm32-cross-build-debug
> + variables:
> +<<: *gcc
> +
> .arm64-build-tmpl:
><<: *build
>variables:
> @@ -454,6 +481,29 @@ alpine-3.12-clang-debug:
> CONTAINER: alpine:3.12
>allow_failure: true
>
> +# Arm32 cross-build
> +
> +debian-unstable-gcc-arm32:
> + extends: .gcc-arm32-cross-build
> + variables:
> +CONTAINER: debian:unstable-arm32-gcc
> +
> +debian-unstable-gcc-arm32-debug:
> + extends: .gcc-arm32-cross-build-debug
> + variables:
> +CONTAINER: debian:unstable-arm32-gcc
> +
> +debian-unstable-gcc-arm32-randconfig:
> + extends: .gcc-arm32-cross-build
> + variables:
> +CONTAINER: debian:unstable-arm32-gcc
> +RANDCONFIG: y
> +
> +debian-unstable-gcc-arm32-debug-randconfig:
> + extends: .gcc-arm32-cross-build-debug
> + variables:
> +CONTAINER: debian:unstable-arm32-gcc
> +RANDCONFIG: y
>
> # Arm builds
>
> diff --git a/automation/scripts/build b/automation/scripts/build
> index d8990c3bf4..e7d68f7a9d 100755
> --- a/automation/scripts/build
> +++ b/automation/scripts/build
> @@ -15,6 +15,15 @@ else
> make -j$(nproc) -C xen defconfig
> fi
>
> +# arm32 only cross-compiles the hypervisor
> +if [[ "${XEN_TARGET_ARCH}" = "arm32" ]]; then
> +make -j$(nproc) xen
> +cp xen/.config xen-config
> +mkdir binaries
> +cp xen/xen binaries/xen
> +exit 0
> +fi
> +
> # build up our configure options
> cfgargs=()
> cfgargs+=("--enable-docs")
> --
> 2.17.1
>
Re: [PATCH 1/2] xen-netback: add module parameter to disable ctrl-ring
+ the author On Tue, Mar 09, 2021 at 07:21:22PM +, Wei Liu wrote: > On Tue, Mar 09, 2021 at 02:34:56PM +, Paul Durrant wrote: > > On 09/03/2021 14:10, Hsu, Chiahao wrote: > > > On 25.02.21, 13:29, "Hsu, Chiahao" wrote: > > > > > > In order to support live migration of guests between kernels > > > that do and do not support 'feature-ctrl-ring', we add a > > > module parameter that allows the feature to be disabled > > > at run time, instead of using hardcode value. > > > The default value is enable. > > > > > > Signed-off-by: ChiaHao Hsu > > > > You should directly CC maintainers, and also I don't see netdev in the To > > list... Did you send it there? I suspect not, since I don't see 'net-next' > > in the prefix. > > I think it would be better to resend this series. > > See Documentation/networking/netdev-FAQ.rst. > > Wei. > > > > > Paul
Re: [PATCH 1/2] xen-netback: add module parameter to disable ctrl-ring
On Tue, Mar 09, 2021 at 02:34:56PM +, Paul Durrant wrote: > On 09/03/2021 14:10, Hsu, Chiahao wrote: > > On 25.02.21, 13:29, "Hsu, Chiahao" wrote: > > > > In order to support live migration of guests between kernels > > that do and do not support 'feature-ctrl-ring', we add a > > module parameter that allows the feature to be disabled > > at run time, instead of using hardcode value. > > The default value is enable. > > > > Signed-off-by: ChiaHao Hsu > > You should directly CC maintainers, and also I don't see netdev in the To > list... Did you send it there? I suspect not, since I don't see 'net-next' > in the prefix. I think it would be better to resend this series. See Documentation/networking/netdev-FAQ.rst. Wei. > > Paul
Re: [PATCH-for-4.15] tools/libs/light: fix xl save -c handling
On Fri, Feb 19, 2021 at 03:13:37PM +0100, Juergen Gross wrote:
> libxl_domain_resume() won't work correctly for the case it was called
> due to a "xl save -c" command, i.e. to continue the suspended domain.
>
> The information to do that is not saved in libxl__dm_resume_state for
> non-HVM domains.
>
> Fixes: 6298f0eb8f443 ("libxl: Re-introduce libxl__domain_resume")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Re: [PATCH for-4.15] automation: Add Ubuntu Focal builds
On Thu, Feb 11, 2021 at 03:57:06PM +, Andrew Cooper wrote: > On 11/02/2021 15:50, Andrew Cooper wrote: > > Logical continuation of c/s eb52442d7f "automation: Add Ubuntu:focal > > container". > > > > No further changes required. Everything builds fine. > > > > Signed-off-by: Andrew Cooper > > --- > > CC: Doug Goldstein > > CC: George Dunlap > > CC: Ian Jackson > > CC: Jan Beulich > > CC: Stefano Stabellini > > CC: Wei Liu > > CC: Julien Grall > > Forgot to say - > https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/254912313 > is a pipeline run with everything green. > > Also, I need to prefix the names with ubuntu- which I can do on commit. Acked-by: Wei Liu
Re: [PATCH for-4.15] tools/libxl: Document where the magic MAC numbers come from
On Wed, Feb 10, 2021 at 01:53:35PM +, Andrew Cooper wrote: > Matches the comment in the xl-network-configuration manpage. > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu
Re: [PATCH v2 4/8] xen/netback: fix spurious event detection for common event case
On Thu, Feb 11, 2021 at 11:16:12AM +0100, Juergen Gross wrote:
> In case of a common event for rx and tx queue the event should be
> regarded to be spurious if no rx and no tx requests are pending.
>
> Unfortunately the condition for testing that is wrong causing to
> decide a event being spurious if no rx OR no tx requests are
> pending.
>
> Fix that plus using local variables for rx/tx pending indicators in
> order to split function calls and if condition.
>
> Fixes: 23025393dbeb3b ("xen/netback: use lateeoi irq binding")
> Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Re: [PATCH 4/7] xen/events: link interdomain events to associated xenbus device
On Sat, Feb 06, 2021 at 11:49:29AM +0100, Juergen Gross wrote: > In order to support the possibility of per-device event channel > settings (e.g. lateeoi spurious event thresholds) add a xenbus device > pointer to struct irq_info() and modify the related event channel > binding interfaces to take the pointer to the xenbus device as a > parameter instead of the domain id of the other side. > > While at it remove the stale prototype of bind_evtchn_to_irq_lateeoi(). > > Signed-off-by: Juergen Gross Reviewed-by: Wei Liu
Re: [PATCH] xen/netback: avoid race in xenvif_rx_ring_slots_available()
On Tue, Feb 02, 2021 at 08:09:38AM +0100, Juergen Gross wrote:
> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> xenvif_rx_ring_slots_available() is no longer called only from the rx
> queue kernel thread, so it needs to access the rx queue with the
> associated queue held.
>
> Reported-by: Igor Druzhinin
> Fixes: 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Re: [PATCH] memory: fix build with COVERAGE but !HVM
On Mon, Feb 01, 2021 at 05:20:54PM +0100, Jan Beulich wrote:
> Xen is heavily relying on the DCE stage to remove unused code so the
> linker doesn't throw an error because a function is not implemented
> yet we defined a prototype for it.
>
> On some GCC versions (such as 9.4 provided by Debian sid), the compiler
> DCE stage will not manage to figure that out for
> xenmem_add_to_physmap_batch():
>
> ld: ld: prelink.o: in function `xenmem_add_to_physmap_batch':
> /xen/xen/common/memory.c:942: undefined reference to
> `xenmem_add_to_physmap_one'
> /xen/xen/common/memory.c:942:(.text+0x22145): relocation truncated
> to fit: R_X86_64_PLT32 against undefined symbol `xenmem_add_to_physmap_one'
> prelink-efi.o: in function `xenmem_add_to_physmap_batch':
> /xen/xen/common/memory.c:942: undefined reference to
> `xenmem_add_to_physmap_one'
> make[2]: *** [Makefile:215: /root/xen/xen/xen.efi] Error 1
> make[2]: *** Waiting for unfinished jobs
> ld: /xen/xen/.xen-syms.0: hidden symbol `xenmem_add_to_physmap_one' isn't
> defined
> ld: final link failed: bad value
>
> It is not entirely clear why the compiler DCE is not detecting the
> unused code. However, cloning the check introduced by the commit below
> into xenmem_add_to_physmap_batch() does the trick.
>
> No functional change intended.
>
> Fixes: d4f699a0df6c ("x86/mm: p2m_add_foreign() is HVM-only")
> Reported-by: Oleksandr Tyshchenko
> Signed-off-by: Julien Grall
> Signed-off-by: Jan Beulich
> Release-Acked-by: Ian Jackson
Reviewed-by: Wei Liu
Re: [PATCH v4] tools/foreignmem: Support querying the size of a resource
On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote: > With the Xen side of this interface (soon to be) fixed to return real sizes, > userspace needs to be able to make the query. > > Introduce xenforeignmemory_resource_size() for the purpose, bumping the > library minor version. > > Update both all osdep_xenforeignmemory_map_resource() implementations to > understand size requests, skip the mmap() operation, and copy back the > nr_frames field. > > For NetBSD, also fix up the ioctl() error path to issue an unmap(), which was > overlooked by c/s 4a64e2bb39 "libs/foreignmemory: Implement on NetBSD". > > Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné Acked-by: Wei Liu
Re: [PATCH] tools/libs: honor build dependencies for recently moved subdirs
On Fri, Jan 22, 2021 at 04:14:30PM +0100, Jan Beulich wrote: > While the lack of proper dependency tracking of #include-d files is > wider than just the libs/ subtree, dealing with the problem universally > there or in tools/Rules.mk is too much of a risk at this point in the > release cycle. Add the missing inclusion of $(DEPS_INCLUDE) only in the > specific Makefile-s, after having checked that their prior Makefile-s > had such includes. > > Interestingly the $(DEPS_RM) use is present in tools/libs/libs.mk's > clean target, so doesn't need taking care of in individual Makefile-s. > > Signed-off-by: Jan Beulich > Release-acked-by: Ian Jackson Acked-by: Wei Liu
Re: [PATCH v1] mm/memory_hotplug: MEMHP_MERGE_RESOURCE -> MHP_MERGE_RESOURCE
On Tue, Jan 26, 2021 at 12:58:29PM +0100, David Hildenbrand wrote: > Let's make "MEMHP_MERGE_RESOURCE" consistent with "MHP_NONE", "mhp_t" and > "mhp_flags". As discussed recently [1], "mhp" is our internal > acronym for memory hotplug now. > > [1] > https://lore.kernel.org/linux-mm/c37de2d0-28a1-4f7d-f944-cfd7d81c3...@redhat.com/ > [...] > Signed-off-by: David Hildenbrand Acked-by: Wei Liu
Re: [PATCH v2 5/5] libxenguest: simplify kernel decompression
On Tue, Jan 19, 2021 at 04:17:12PM +0100, Jan Beulich wrote:
> In all cases the kernel build makes available the uncompressed size in
> the final 4 bytes of the bzImage payload. Utilize this to avoid
> repeated realloc()ing of the output buffer.
>
> As a side effect this also addresses the previous mistaken return of 0
> (success) from xc_try_{bzip2,lzma,xz}_decode() in case
> xc_dom_register_external() would have failed.
>
> As another side effect this also addresses the first error path of
> _xc_try_lzma_decode() previously bypassing lzma_end().
>
> Signed-off-by: Jan Beulich
I think the code changes are correct:
Acked-by: Wei Liu
But a second pair of eyes would be useful here since this patch is
complex.
Wei.
Re: [PATCH v2 1/5] libxenguest: support zstd compressed kernels
On Thu, Jan 21, 2021 at 04:05:39PM +0100, Jan Beulich wrote:
> On 21.01.2021 16:01, Wei Liu wrote:
> > On Tue, Jan 19, 2021 at 04:15:25PM +0100, Jan Beulich wrote:
> >> This follows the logic used for other decompression methods utilizing an
> >> external library, albeit here we can't ignore the 32-bit size field
> >> appended to the compressed image - its presence causes decompression to
> >> fail. Leverage the field instead to allocate the output buffer in one
> >> go, i.e. without incrementally realloc()ing.
> >>
> >> Note that, where possible, instead of #ifdef-ing xen/*.h inclusions,
> >> they get removed.
> >>
> >> Signed-off-by: Jan Beulich
> >
> >
> > Acked-by: Wei Liu
>
> Thanks, but I'm about to send v2.5 to address the issue reported
> by Michael Young (adjusting configure{.ac,} only).
>
> >> ---
> >> Note for committer: As an alternative to patching tools/configure here,
> >> autoconf may want re-running.
> >
> > Noted. FWIW I use Debian 10 to generate configure. If I don't get around
> > doing it someone who runs the same system should be able to help.
>
> Well, the version I've been using to re-generate isn't identical
> to yours, but allows easily filtering out and discarding the few
> extra differences, which is why I dared to provide a diff for
> tools/configure in the first place. IOW if I would commit this
> myself, all I would ask that you or someone else using the
> "original" autoconf to generate the committed version to double
> check.
This works too.
Wei.
>
> Jan
Re: [PATCH v2 4/5] libxenguest: drop redundant decompression declarations
On Tue, Jan 19, 2021 at 04:16:53PM +0100, Jan Beulich wrote: > The ones in xg_dom_decompress_unsafe.h suffice. > > Signed-off-by: Jan Beulich Acked-by: Wei Liu
Re: [PATCH v2 3/5] libxenguest: "standardize" LZO kernel decompression code
On Tue, Jan 19, 2021 at 04:16:35PM +0100, Jan Beulich wrote: > Add a DOMPRINTF() other methods have, indicating success. To facilitate > this, introduce an "outsize" local variable and update *size as well as > *blob only once done. The latter then also avoids leaving a pointer to > freed memory in dom->kernel_blob in case of a decompression error. > > Signed-off-by: Jan Beulich Acked-by: Wei Liu
Re: [PATCH v2 2/5] xen/decompress: make helper symbols static
On Tue, Jan 19, 2021 at 04:15:53PM +0100, Jan Beulich wrote: > The individual decompression CUs need to only surface their top level > functions to other code. Arrange for everything else to be static, to > make sure no undue uses of that code exist or will appear without > explicitly noticing. (In some cases this also results in code size > reduction, but since this is all init-only code this probably doesn't > matter very much.) > > In the LZO case also take the opportunity and convert u8 where lines > get touched anyway. > > The downside is that the top level functions will now be non-static > in stubdom builds of libxenguest, but I think that's acceptable. This > does require declaring them first, though, as the compiler warns about > the lack of declarations. > > Signed-off-by: Jan Beulich > Acked-by: Andrew Cooper Acked-by: Wei Liu
Re: [PATCH v2 1/5] libxenguest: support zstd compressed kernels
On Tue, Jan 19, 2021 at 04:15:25PM +0100, Jan Beulich wrote: > This follows the logic used for other decompression methods utilizing an > external library, albeit here we can't ignore the 32-bit size field > appended to the compressed image - its presence causes decompression to > fail. Leverage the field instead to allocate the output buffer in one > go, i.e. without incrementally realloc()ing. > > Note that, where possible, instead of #ifdef-ing xen/*.h inclusions, > they get removed. > > Signed-off-by: Jan Beulich Acked-by: Wei Liu > --- > Note for committer: As an alternative to patching tools/configure here, > autoconf may want re-running. Noted. FWIW I use Debian 10 to generate configure. If I don't get around doing it someone who runs the same system should be able to help.
Re: [PATCH v2 4/4] tools/libs: Apply MSR policy to a guest
On Wed, Jan 20, 2021 at 05:49:12PM -0500, Boris Ostrovsky wrote: > When creating a guest, if ignore_msrs option has been specified, > apply it to guest's MSR policy. > > Signed-off-by: Boris Ostrovsky Acked-by: Wei Liu
Re: [PATCH v2 1/4] xl: Add support for ignore_msrs option
On Wed, Jan 20, 2021 at 05:49:09PM -0500, Boris Ostrovsky wrote: > This option allows guest administrator specify what should happen when > guest accesses an MSR which is not explicitly emulated by the hypervisor. > > Signed-off-by: Boris Ostrovsky > --- > docs/man/xl.cfg.5.pod.in | 20 +++- > tools/libs/light/libxl_types.idl | 7 +++ > tools/xl/xl_parse.c | 7 +++ > 3 files changed, 33 insertions(+), 1 deletion(-) It is mainly missing a #define LIBXL_HAVE_XXX in libxl.h. Other than that, this patch looks good to me. If you end up resending this series, please fix that issue. If other patches are all reviewed, you can provide some text to be merged into this patch. Wei.
Re: [PATCH v7 7/7] libxl / libxlu: support 'xl pci-attach/detach' by name
On Tue, Jan 05, 2021 at 05:46:42PM +, Paul Durrant wrote: > 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_pci_add() and > libxl_device_pci_remove() will use it to look up the device BDF in > the list of assignable devices. > > Signed-off-by: Paul Durrant Acked-by: Wei Liu
Re: [PATCH v7 5/7] xl: support naming of assignable devices
On Tue, Jan 05, 2021 at 05:46:40PM +, Paul Durrant wrote: > 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 output. > > Signed-off-by: Paul Durrant Acked-by: Wei Liu
Re: [PATCH v7 4/7] libxl: add 'name' field to 'libxl_device_pci' in the IDL...
On Tue, Jan 05, 2021 at 05:46:39PM +, Paul Durrant wrote: > 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, looking up the BDF as necessary. > > libxl_pci_bdf_assignable_list() will also populate the 'name' field if a name > was stored by libxl_pci_bdf_assignable_add(). > > NOTE: This patch also fixes whitespace in the declaration of > 'libxl_device_pci' > in the IDL. > > Signed-off-by: Paul Durrant Acked-by: Wei Liu
Re: [PATCH v7 3/7] libxl: stop setting 'vdevfn' in pci_struct_fill()
On Tue, Jan 05, 2021 at 05:46:38PM +, Paul Durrant wrote: > 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 will also make use of pci_struct_fill() in a context > where 'vdevfn' may already have been set. > > Signed-off-by: Paul Durrant Acked-by: Wei Liu
Re: [PATCH 0/3] automation: build qemu-system-aarch64 and use it for tests
On Tue, Jan 05, 2021 at 02:58:38PM -0800, Stefano Stabellini wrote: > 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 test-artifacts, which are only > built once, then imported into each pipeline via phony jobs. Use the > provided qemu-system-aarch64 binary for our arm64 tests. > > > Stefano Stabellini (3): > automation: add qemu-system-aarch64 to test-artifacts > automation: add a job to import qemu-system-aarch64 into the pipeline > automation: use test-artifacts/qemu-system-aarch64 instead of Debian's Acked-by: Wei Liu I do wonder if there is a way to not build QEMU during every pipeline run though...
Re: [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
Typo in subject line ("it's").
Re: [PATCH v1] tools: ipxe: update for fixing build with GCC10 [and 1 more messages]
On Wed, Jan 06, 2021 at 11:25:34AM +, Wei Liu wrote:
> On Wed, Jan 06, 2021 at 11:23:43AM +, Ian Jackson wrote:
> > Wei Liu writes ("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
> > ...
> > > > -IPXE_GIT_TAG := 1dd56dbd11082fb622c2ed21cfaced4f47d798a6
> > > > +IPXE_GIT_TAG := 988d2c13cdf0f0b4140685af35ced70ac5b3283c
> >
> > Unfortunately this broke the build, but it's not really your fault:
> >
> > osstest service owner writes ("[xen-unstable-smoke test] 158191:
> > regressions - FAIL"):
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > > build-amd64 6 xen-buildfail REGR. vs.
> > > 158134
> >
> > --2021-01-06 01:27:19--
> > http://xenbits.xen.org/xen-extfiles/ipxe-git-988d2c13cdf0f0b4140685af35ced70ac5b3283c.tar.gz
> > Resolving cache (cache)... 172.16.148.6
> > Connecting to cache (cache)|172.16.148.6|:3128... connected.
> > Proxy request sent, awaiting response... 404 Not Found
> >
> > We currently insist on having have a tarball.
> >
> > That means someone (me, I guess) has to do a "git archive" and put the
> > resulting tarball in the right place on xenbits. Unfortunately this
> > is still manual, but we don't update ipxe very often.
> >
>
> Wouldn't the build host just fetch from the upstream git tree? That's
> why I didn't ask you to make a tarball -- I was waiting to see if this
> could pass osstest before asking.
>
Never mind. It seems that I have missed the change of requirement...
Wei.
Re: [PATCH v1] tools: ipxe: update for fixing build with GCC10 [and 1 more messages]
On Wed, Jan 06, 2021 at 11:23:43AM +, Ian Jackson wrote:
> Wei Liu writes ("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
> ...
> > > -IPXE_GIT_TAG := 1dd56dbd11082fb622c2ed21cfaced4f47d798a6
> > > +IPXE_GIT_TAG := 988d2c13cdf0f0b4140685af35ced70ac5b3283c
>
> Unfortunately this broke the build, but it's not really your fault:
>
> osstest service owner writes ("[xen-unstable-smoke test] 158191: regressions
> - FAIL"):
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-amd64 6 xen-buildfail REGR. vs.
> > 158134
>
> --2021-01-06 01:27:19--
> http://xenbits.xen.org/xen-extfiles/ipxe-git-988d2c13cdf0f0b4140685af35ced70ac5b3283c.tar.gz
> Resolving cache (cache)... 172.16.148.6
> Connecting to cache (cache)|172.16.148.6|:3128... connected.
> Proxy request sent, awaiting response... 404 Not Found
>
> We currently insist on having have a tarball.
>
> That means someone (me, I guess) has to do a "git archive" and put the
> resulting tarball in the right place on xenbits. Unfortunately this
> is still manual, but we don't update ipxe very often.
>
Wouldn't the build host just fetch from the upstream git tree? That's
why I didn't ask you to make a tarball -- I was waiting to see if this
could pass osstest before asking.
> I have made the tarball now.
Thanks.
Wei.
>
> Ian.
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 XSM_TARGET:
> > -if ( src == target )
> > +if ( evaluate_nospec(src == target) )
> > {
> > return 0;
> > case XSM_XS_PRIV:
> > -if ( is_xenstore_domain(src) )
> > +if ( evaluate_nospec(is_xenstore_domain(src)) )
> > return 0;
> > }
> > /* fall through */
> > case XSM_DM_PRIV:
> > -if ( target && src->target == target )
> > +if ( target && evaluate_nospec(src->target == target) )
> > return 0;
> > /* fall through */
> > case XSM_PRIV:
> > -if ( src->is_privileged )
> > +if ( !is_control_domain(src) )
> > return 0;
> > return -EPERM;
>
> And a stray ! slipped in here. Now fixed.
FWIW:
Reviewed-by: Wei Liu
>
> Jan
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 > (the contents of Xenstore, all connections to various clients like > programs or other domains, and watches) is saved in a defined format > and a new binary is being activated consuming the old state. All > connections are being restored and the new Xenstore binary will > continue where the old one stopped. > > This patch series has been under (secret) development for quite some > time. It hasn't been posted to xen-devel until now due to the various > Xenstore related security issues which have become public only today. > > There will be a similar series for oxenstored posted. > > Xenstore-stubdom is not yet supported, but I'm planning to start > working on that soon. > > Changes in V10 (for the members of the security team): > - dropped patch 6 as requested by Andrew I went through this series when it was posted to security@ and didn't find that many issues. I guess I will wait for Andrew's comment to be addressed and have a look again. Wei.
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 case of > > driver domain, it has no access to remove all of them - specifically the > > directory named after frontend-id remains. This may accumulate enough to > > exceed xenstore quote of the driver domain, breaking further devices. > > > > Fix this by calling libxl__xs_path_cleanup() on the backend path from > > libxl__device_destroy() in the toolstack domain too. Note > > libxl__device_destroy() is called when the driver domain already removed > > what it can (see device_destroy_be_watch_cb()->device_hotplug_done()). > > > > Signed-off-by: Marek Marczykowski-Górecki > > Ping? Acked-by: Wei Liu
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 produce a custom date if SOURCE_DATE_EPOCH is defined. > > If SOURCE_DATE_EPOCH is not defined or no suitable date command was > > found, use the current date. This enables reproducible builds. > > > > Signed-off-by: Maximilian Engelhardt > > > > Changes in v2: > > - add capability detection for the 'date' command using ax_prog_date.m4 > > - add information about detected date command to config/Docs.mk > > - only call a supported date command in docs/Makefile > > --- > > Please note the ax_prog_date.m4 macro is taken from the autoconf-archive > > repository [1] and it's license is GPL v3 or later with an exception for > > the generated configure script. > > > > [1] https://www.gnu.org/software/autoconf-archive/ > > --- > > config/Docs.mk.in | 3 + > > docs/Makefile | 16 +++- > > docs/configure | 213 + > > docs/configure.ac | 9 ++ > > m4/ax_prog_date.m4 | 139 + > > 5 files changed, 379 insertions(+), 1 deletion(-) > > create mode 100644 m4/ax_prog_date.m4 > > Wait, what. The comment about the -d option already existing since 2005 > (in the previous thread) is relevant here... > > I guess there would be other reasons why the whole current Xen master > branch would not compile on e.g. Debian Sarge 3.1 from 2005... Like, > amd64 did not even exist as release architecture yet, back then... > > I'd prefer > > 1 file changed, 7 insertions(+), 1 deletion(-) > > over > > 5 files changed, 379 insertions(+), 1 deletion(-) > > in this case. > I have not read the previous thread. I would rather prefer a smaller patch than a larger one. I agree with Hans here. Maximilian, what do you think? Wei.
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 insertion(+), 1 deletion(-) > > diff --git a/tools/firmware/etherboot/Makefile > b/tools/firmware/etherboot/Makefile > index 0de30599bf..ed9e11305f 100644 > --- a/tools/firmware/etherboot/Makefile > +++ b/tools/firmware/etherboot/Makefile > @@ -10,7 +10,7 @@ else > IPXE_GIT_URL ?= git://git.ipxe.org/ipxe.git > endif > > -IPXE_GIT_TAG := 1dd56dbd11082fb622c2ed21cfaced4f47d798a6 > +IPXE_GIT_TAG := 988d2c13cdf0f0b4140685af35ced70ac5b3283c > > IPXE_TARBALL_URL ?= $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz >
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 be more specific.
>
> > ---
> > 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/xenguest.h
> > +++ b/tools/include/xenguest.h
> > @@ -438,7 +438,7 @@ struct xenevtchn_handle;
> > struct precopy_stats
> > {
> > unsigned int iteration;
> > -unsigned int total_written;
> > +unsigned long total_written;
> > long dirty_count; /* -1 if unknown */
> > };
> >
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/xenguest.h b/tools/include/xenguest.h
> index a9984dbea5..775cf34c04 100644
> --- a/tools/include/xenguest.h
> +++ b/tools/include/xenguest.h
> @@ -438,7 +438,7 @@ struct xenevtchn_handle;
> struct precopy_stats
> {
> unsigned int iteration;
> -unsigned int total_written;
> +unsigned long total_written;
> long dirty_count; /* -1 if unknown */
> };
>
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: [xen-unstable-smoke bisection] complete build-amd64-libvirt
On Wed, Dec 16, 2020 at 10:43:57AM +, Wei Liu wrote: > Paul, are you able to cook up a patch today? If not I will revert the > offending patch(es). > I've reverted the offending 8 patches for now. Wei.
Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
Paul, are you able to cook up a patch today? If not I will revert the
offending patch(es).
Wei.
On Wed, Dec 16, 2020 at 10:17:29AM +, Andrew Cooper wrote:
> On 16/12/2020 02:27, osstest service owner wrote:
> > branch xen-unstable-smoke
> > xenbranch xen-unstable-smoke
> > job build-amd64-libvirt
> > testid libvirt-build
> >
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
> > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> > Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> > Tree: xen git://xenbits.xen.org/xen.git
> >
> > *** Found and reproduced problem changeset ***
> >
> > Bug is in tree: xen git://xenbits.xen.org/xen.git
> > Bug introduced: 929f23114061a0089e6d63d109cf6a1d03d35c71
> > Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
> > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/
> >
> >
> > commit 929f23114061a0089e6d63d109cf6a1d03d35c71
> > Author: Paul Durrant
> > Date: Tue Dec 8 19:30:26 2020 +
> >
> > libxl: introduce 'libxl_pci_bdf' in the idl...
> >
> > ... and use in 'libxl_device_pci'
> >
> > This patch is preparatory work for restricting the type passed to
> > functions
> > that only require BDF information, rather than passing a
> > 'libxl_device_pci'
> > structure which is only partially filled. In this patch only the
> > minimal
> > mechanical changes necessary to deal with the structural changes are
> > made.
> > Subsequent patches will adjust the code to make better use of the new
> > type.
> >
> > Signed-off-by: Paul Durrant
> > Acked-by: Wei Liu
> > Acked-by: Nick Rosbrook
>
> This breaks the API. You can't make the following change in the IDL.
>
> libxl_device_pci = Struct("device_pci", [
> - ("func", uint8),
> - ("dev", uint8),
> - ("bus", uint8),
> - ("domain", integer),
> - ("vdevfn", uint32),
> + ("bdf", libxl_pci_bdf),
> + ("vdevfn", uint32),
>
> ~Andrew
Re: [PATCH v1 3/3] tools: add API to work with sevaral bits at once
On Tue, Dec 15, 2020 at 05:29:17PM +0100, Olaf Hering wrote: > Am Tue, 15 Dec 2020 16:22:44 + > schrieb Wei Liu : > > > What's wrong with requiring the input addr be const unsigned long *? > > Probably nothing. In the end I just borrowed the prototypes from the other > functions in this file. > > I will resend with this change once I have the consumers ready. Okay. I will push the first two shortly. Wei. > > Olaf
Re: [PATCH v2 3/4] x86/PV: avoid double stack reset during schedule tail handling
On Tue, Dec 15, 2020 at 05:12:36PM +0100, Jan Beulich wrote: > Invoking check_wakeup_from_wait() from assembly allows the new > continue_pv_domain() to replace the prior continue_nonidle_domain() as > the tail hook, eliminating an extra reset_stack_and_jump(). > > Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross Reviewed-by: Wei Liu
Re: [PATCH v2 2/4] x86: clobber registers in switch_stack_and_jump() when !LIVEPATCH
On Tue, Dec 15, 2020 at 05:12:12PM +0100, Jan Beulich wrote: > In order to have the same effect on registers as a call to > check_for_livepatch_work() may have, clobber all call-clobbered > registers in debug builds. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu
Re: [PATCH v2 1/4] x86: verify function type (and maybe attribute) in switch_stack_and_jump()
On Tue, Dec 15, 2020 at 05:11:41PM +0100, Jan Beulich wrote: > It is imperative that the functions passed here are taking no arguments, > return no values, and don't return in the first place. While the type > can be checked uniformly, the attribute check is limited to gcc 9 and > newer (no clang support for this so far afaict). > > Note that I didn't want to have the "true" fallback "implementation" of > __builtin_has_attribute(..., __noreturn__) generally available, as > "true" may not be a suitable fallback in other cases. > > Note further that the noreturn addition to startup_cpu_idle_loop()'s > declaration requires adding unreachable() to Arm's > switch_stack_and_jump(), or else the build would break. I suppose this > should have been there already. > > For vmx_asm_do_vmentry() along with adding the attribute, also restrict > its scope. > > Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross Reviewed-by: Wei Liu
Re: [PATCH v1 3/3] tools: add API to work with sevaral bits at once
On Wed, Dec 09, 2020 at 04:54:51PM +0100, Olaf Hering wrote: > Introduce new API to test if a fixed number of bits is clear or set, > and clear or set them all at once. > > The caller has to make sure the input bitnumber is a multiply of > BITS_PER_LONG. > > This API avoids the loop over each bit in a known range just to see > if all of them are either clear or set. > > Signed-off-by: Olaf Hering I would rather these be introduced along side their callers. > --- > tools/libs/ctrl/xc_bitops.h | 25 + > 1 file changed, 25 insertions(+) > > diff --git a/tools/libs/ctrl/xc_bitops.h b/tools/libs/ctrl/xc_bitops.h > index f0bac4a071..92f38872fb 100644 > --- a/tools/libs/ctrl/xc_bitops.h > +++ b/tools/libs/ctrl/xc_bitops.h > @@ -77,4 +77,29 @@ static inline void bitmap_or(void *_dst, const void > *_other, > dst[i] |= other[i]; > } > > +static inline int test_bit_long_set(unsigned long nr_base, const void *_addr) What's wrong with requiring the input addr be const unsigned long *?
Re: [PATCH v1 2/3] tools: remove unused ORDER_LONG
On Wed, Dec 09, 2020 at 04:54:50PM +0100, Olaf Hering wrote: > There are no users left, xenpaging has its own variant. > The last user was removed with commit 11d0044a168994de85b9b328452292852aedc871 > > Signed-off-by: Olaf Hering Acked-by: Wei Liu
Re: [PATCH v1 1/3] tools: allocate bitmaps in units of unsigned long
On Wed, Dec 09, 2020 at 04:54:49PM +0100, Olaf Hering wrote:
> Allocate enough memory so that the returned pointer can be safely
> accessed as an array of unsigned long.
>
> The actual bitmap size in units of bytes, as returned by bitmap_size,
> remains unchanged.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
I can see where you're coming from. This (internal) API's returned
pointer is being assigned to unsigned long *.
> ---
> tools/libs/ctrl/xc_bitops.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libs/ctrl/xc_bitops.h b/tools/libs/ctrl/xc_bitops.h
> index 3d3a09772a..d6c5ea5138 100644
> --- a/tools/libs/ctrl/xc_bitops.h
> +++ b/tools/libs/ctrl/xc_bitops.h
> @@ -21,7 +21,10 @@ static inline unsigned long bitmap_size(unsigned long
> nr_bits)
>
> static inline void *bitmap_alloc(unsigned long nr_bits)
> {
> -return calloc(1, bitmap_size(nr_bits));
> +unsigned long longs;
> +
> +longs = (nr_bits + BITS_PER_LONG - 1) / BITS_PER_LONG;
> +return calloc(longs, sizeof(unsigned long));
> }
>
> static inline void bitmap_set(void *addr, unsigned long nr_bits)
Re: [PATCH v6 23/25] xl: support naming of assignable devices
On Tue, Dec 08, 2020 at 07:30:31PM +, Paul Durrant wrote: > From: Paul Durrant > > This patch converts libxl to use libxl_pci_bdf_assignable_add/remove/list/ > list_free() rather than libxl_device_pci_assignable_add/remove/list/ > list_free(), which then allows naming of assignable devices to be supported. > > 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 output. > > Signed-off-by: Paul Durrant Acked-by: Wei Liu
Re: [PATCH v6 22/25] libxl: introduce libxl_pci_bdf_assignable_add/remove/list/list_free(), ...
On Tue, Dec 08, 2020 at 07:30:30PM +, Paul Durrant wrote: > From: Paul Durrant > > which support naming and use 'libxl_pci_bdf' rather than 'libxl_device_pci', > as replacements for libxl_device_pci_assignable_add/remove/list/list_free(). > > libxl_pci_bdf_assignable_add() takes a 'name' parameter which is stored in > xenstore and facilitates two addtional functions added by this patch: > libxl_pci_bdf_assignable_name2bdf() and libxl_pci_bdf_assignable_bdf2name(). > Currently there are no callers of these two functions. They will be added in > a subsequent patch. > > libxl_device_pci_assignable_add/remove/list/list_free() are left in place > for compatibility but are re-implemented in terms of the newly introduced > functions. > > Signed-off-by: Paul Durrant > --- > Cc: Ian Jackson > Cc: Wei Liu > Cc: Anthony PERARD Acked-by: Wei Liu
