From: "Longpeng(Mike)"
A CPU will not show up in virtualized environment which includes an
Enclave. The VM splits its resources into a primary VM and a Enclave
VM. While the Enclave is active, the hypervisor will ignore all requests
to bring up a CPU and this CPU will remain in CPU_UP_PREPARE sta
This is a another repost of the previous patch (#2) and adding Boris
(Ostrovsky)'s suggestion regarding the XEN bits.
The previous posts can be found at
https://lore.kernel.org/all/20211206152034.2150770-1-bige...@linutronix.de/
https://lore.kernel.org/all/20211122154714.xaoxok3fpk5bg...@linu
From: Boris Ostrovsky
If memory allocation in cpu_initialize_context() fails then it will
bring up the VCPU and leave with the corresponding CPU bit set in
xen_cpu_initialized_map.
The following (presumably successful) CPU bring up will BUG in
xen_pv_cpu_up() because nothing for that VCPU would b
flight 168068 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168068/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 52ce1c97844db213de01c5300eaaa8cf101a285f
baseline version:
xen 820c
On 08.02.22 14:47, Jan Beulich wrote:
Hi Julien, Jan
> On 08.02.2022 12:58, Julien Grall wrote:
>> On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
>>> On 07.02.22 19:15, Julien Grall wrote:
Hi Oleksandr,
On 05/01/2022 23:11, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchen
Hi Julien,
On Tue, Feb 08, 2022 at 06:26:54PM +, Julien Grall wrote:
> Hi Oleksii,
>
> On 08/02/2022 18:00, Oleksii Moisieiev wrote:
> > If enabled, host device-tree will be exported to hypfs and can be
> > accessed through /devicetree path.
> > Exported device-tree has the same format, as th
This is not a bug. The xen cmdline can request both a NUMA restriction
and a vcpu count restriction for Dom0. The node restriction wil always
be respected which might mean either using dom0_max_vcpus <
opt_dom0_max_vcpus_max or using more vCPUs than pCPUs on a node. In
the case where dom0_max_vcpus
On 09/02/2022 10:31, Jane Malalane wrote:
> This is not a bug. The xen cmdline can request both a NUMA restriction
> and a vcpu count restriction for Dom0. The node restriction wil always
> be respected which might mean either using dom0_max_vcpus <
> opt_dom0_max_vcpus_max or using more vCPUs than
flight 168064 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168064/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168055
test-amd64-amd64-qemuu-nested-amd 20
flight 168063 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168063/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168015
test-amd64-amd64-xl-qemuu-win7-a
On 08/02/2022 16:17, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 06:21:01PM +, Jane Malalane wrote:
>> Introduce a new per-domain creation x86 specific flag to
>> select whether hardware assisted virtualization should be used for
>> x{2}APIC.
>>
>> A per-domain option is added to xl in ord
On 09.02.2022 11:08, Oleksandr Tyshchenko wrote:
>
> On 08.02.22 14:47, Jan Beulich wrote:
>
>
> Hi Julien, Jan
>
>
>> On 08.02.2022 12:58, Julien Grall wrote:
>>> On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
On 07.02.22 19:15, Julien Grall wrote:
> Hi Oleksandr,
> On 05/01/20
Previously, Xen used information from the BDA to detect the amount of
available low memory. This does not work on some scenarios such as
Coreboot, or when booting from Kexec on a UEFI system without CSM.
Use the information directly supplied by Multiboot boot information
instead.
---
xen/arch/x86
Hi Stefano,
Thanks for your feedback.
On 09/02/2022 01:50, Stefano Stabellini wrote:
On Sat, 5 Feb 2022, Ayan Kumar Halder wrote:
@@ -95,6 +97,7 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
bool arch_ioreq_complete_mmio(void)
{
struct vcpu *v = current;
+struct i
On 09.02.2022 12:00, dinhngoc...@irit.fr wrote:
> Previously, Xen used information from the BDA to detect the amount of
> available low memory. This does not work on some scenarios such as
> Coreboot, or when booting from Kexec on a UEFI system without CSM.
>
> Use the information directly supplie
On 09.02.2022 11:31, Jane Malalane wrote:
> This is not a bug. The xen cmdline can request both a NUMA restriction
> and a vcpu count restriction for Dom0. The node restriction wil always
> be respected which might mean either using dom0_max_vcpus <
> opt_dom0_max_vcpus_max
This is quite normal a
> The comment here is a pretty clear indication that bad values may have been
> observed, even if this was only in the distant past. But we have to not
> regress even on very old boot loaders.
>
> Is the kexec case recognizable by any means (including to distinguish kexec
> properly communicating
On 09/02/2022 10:20, Oleksii Moisieiev wrote:
Hi Julien,
Hi,
On Tue, Feb 08, 2022 at 06:26:54PM +, Julien Grall wrote:
Hi Oleksii,
On 08/02/2022 18:00, Oleksii Moisieiev wrote:
If enabled, host device-tree will be exported to hypfs and can be
accessed through /devicetree path.
Expo
Hi,
On 08/02/2022 11:23, Volodymyr Babchuk wrote:
HSCIF is a high-speed variant of Renesas SCIF serial interface. From
Xen point of view, they almost the same, only difference is in FIFO
size.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
And co
On 08/02/2022 15:26, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 06:21:00PM +, Jane Malalane wrote:
>> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
>> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
>> and x2apic, on x86 hardware.
>> No such features are currently imp
Hi,
On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini
We are passing an internal-only boolean flag at domain creation to
specify whether we want the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.
This commit extends original "b
Hi,
On 27/01/2022 07:49, Penny Zheng wrote:
+- direct-map
+
+Only available when statically allocated memory is used for the domain.
+An empty property to request the memory of the domain to be
+direct-map (guest physical address == physical address).
NIT: I would add "host" just a
Previously, we do not make use of the framebuffer given by Multiboot.
This means graphics will not work in some scenarios such as booting from
Kexec.
Enable the Multiboot framebuffer if it exists and not overridden by EFI
probe.
---
xen/arch/x86/setup.c | 45 ++
Multiboot2 exposes framebuffer data in its boot information tags. Xen
requests this information from the bootloader, but does not make use of
it.
Parse this information for later use.
---
xen/arch/x86/boot/reloc.c| 22 ++
xen/include/xen/multiboot.h | 17 +
Xen does not currently use the Multiboot framebuffer. This means there
is no graphics when booting Xen with Kexec.
This patchset parses and uses the Multiboot framebuffer information
during boot.
Tu Dinh Ngoc (2):
x86: Parse Multiboot2 framebuffer information
x86: Set up framebuffer given by
Previously, Xen used information from the BDA to detect the amount of
available low memory. This does not work on some scenarios such as
Coreboot, or when booting from Kexec on a UEFI system without CSM.
Use the information directly supplied by Multiboot boot information
instead.
---
xen/arch/x86
On 09.02.2022 13:42, Julien Grall wrote:
> On 27/01/2022 07:49, Penny Zheng wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -722,7 +722,8 @@ static bool emulation_flags_ok(const struct domain *d,
>> uint32_t emflags)
>> }
>>
>> int arch_domain_create(struct domain
From: Oleksandr Andrushchenko
Introduce a per-domain read/write lock to check whether vpci is present,
so we are sure there are no accesses to the contents of the vpci struct
if not. This lock can be used (and in a few cases is used right away)
so that vpci removal can be performed while holding
On 09.02.2022 14:09, Tu Dinh Ngoc wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -156,6 +156,8 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> multiboot_info_t *mbi_out;
> u32 ptr;
> unsigned int i, mod_idx = 0;
> +u64 fbaddr;
> +u8 fbtyp
Hi, Oleksii!
On 08.02.22 20:00, Oleksii Moisieiev wrote:
> libxenhypfs will return blob properties as is. This output can be used
> to retrieve information from the hypfs. Caller is responsible for
> parsing property value.
>
> Signed-off-by: Oleksii Moisieiev
> ---
> tools/libs/hypfs/core.c |
On Wed, Feb 09, 2022 at 12:26:05PM +, Jane Malalane wrote:
> On 08/02/2022 15:26, Roger Pau Monné wrote:
> > On Mon, Feb 07, 2022 at 06:21:00PM +, Jane Malalane wrote:
> >> diff --git a/tools/golang/xenlight/types.gen.go
> >> b/tools/golang/xenlight/types.gen.go
> >> index b1e84d5258..5f38
On 09.02.2022 14:09, Tu Dinh Ngoc wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -551,16 +551,55 @@ struct boot_video_info {
> extern struct boot_video_info boot_vid_info;
> #endif
>
> -static void __init parse_video_info(void)
> +static void __init parse_video_info(multi
On 09.02.2022 14:47, Oleksandr Andrushchenko wrote:
> Hi, Oleksii!
>
> On 08.02.22 20:00, Oleksii Moisieiev wrote:
>> libxenhypfs will return blob properties as is. This output can be used
>> to retrieve information from the hypfs. Caller is responsible for
>> parsing property value.
>>
>> Signed-
On 08.02.22 19:26, Julien Grall wrote:
Hi Oleksii,
On 08/02/2022 18:00, Oleksii Moisieiev wrote:
If enabled, host device-tree will be exported to hypfs and can be
accessed through /devicetree path.
Exported device-tree has the same format, as the device-tree
exported to the sysfs by the Linux k
On 08.02.22 19:00, Oleksii Moisieiev wrote:
libxenhypfs will return blob properties as is. This output can be used
to retrieve information from the hypfs. Caller is responsible for
parsing property value.
Signed-off-by: Oleksii Moisieiev
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9
On 09.02.22 16:01, Jan Beulich wrote:
> On 09.02.2022 14:47, Oleksandr Andrushchenko wrote:
>> Hi, Oleksii!
>>
>> On 08.02.22 20:00, Oleksii Moisieiev wrote:
>>> libxenhypfs will return blob properties as is. This output can be used
>>> to retrieve information from the hypfs. Caller is responsibl
On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini
When IOMMU is absent or shall not be used (trusted domain, performance,
hardware limitation, ..., etc), in which cases this commit avoids setting
XEN_DOMCTL_CDF_iommu to make those user cases possible and prevent failure
later
Hi Julien,
On Wed, Feb 09, 2022 at 12:17:17PM +, Julien Grall wrote:
>
>
> On 09/02/2022 10:20, Oleksii Moisieiev wrote:
> > Hi Julien,
>
> Hi,
>
> >
> > On Tue, Feb 08, 2022 at 06:26:54PM +, Julien Grall wrote:
> > > Hi Oleksii,
> > >
> > > On 08/02/2022 18:00, Oleksii Moisieiev wro
On 09.02.2022 14:12, Tu Dinh Ngoc wrote:
> Previously, Xen used information from the BDA to detect the amount of
> available low memory. This does not work on some scenarios such as
> Coreboot, or when booting from Kexec on a UEFI system without CSM.
>
> Use the information directly supplied by Mu
Hi, Oleksii!
On 08.02.22 20:00, Oleksii Moisieiev wrote:
> This is the implementation of SCI interface, called SCMI-SMC driver,
> which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
> This allows devices from the Domains to work with clocks, resets and
> power-domains with
On 09.02.2022 14:09, Tu Dinh Ngoc wrote:
> Xen does not currently use the Multiboot framebuffer. This means there
> is no graphics when booting Xen with Kexec.
>
> This patchset parses and uses the Multiboot framebuffer information
> during boot.
>
> Tu Dinh Ngoc (2):
> x86: Parse Multiboot2 fr
Hi Penny,
On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
all domains that are direct-mapped.
NEW VGIC has different n
Hi Penny,
On 27/01/2022 07:49, Penny Zheng wrote:
diff --git a/xen/arch/arm/include/asm/domain.h
b/xen/arch/arm/include/asm/domain.h
index cb37ce89ec..848fec8a0f 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -31,6 +31,20 @@ enum domain_type {
#de
Hi Penny,
On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini
We always use a fix address to map the vPL011 to domains. The address
could be a problem for direct-map domains.
So, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid
Hi Penny,
On 27/01/2022 07:49, Penny Zheng wrote:
From: Stefano Stabellini
This commit creates a new doc to document how to do passthrough without IOMMU.
Signed-off-by: Stefano Stabellini
Signed-off-by: Penny Zheng
Tested-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
--
Julien
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, 9 February 2022 15:26
> To: Tu Dinh Ngoc
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2] x86: Use low memory size directly from Multiboot
>
> On 09.02.2022 14:12, Tu Dinh Ngoc wrote:
> > Previously, Xen used infor
On 09.02.2022 16:20, dinhngoc...@irit.fr wrote:
> This change should only affect the particular case of booting with Multiboot2
> without EFI (e.g. legacy BIOS or Kexec). Other cases like Multiboot 0.x, EFI
> booting (with or without MB2), or bootloaders that generate the BASIC_MEMINFO
> tag cor
On 09/02/2022 15:02, Oleksandr Andrushchenko wrote:
+{
+return FIELD_PREP(HDR_ID, hdr->id) |
+FIELD_PREP(HDR_TYPE, hdr->type) |
+FIELD_PREP(HDR_PROTO, hdr->protocol);
+}
+
+/*
+ * unpack_scmi_header() - unpacks and records message and protocol id
+ *
+ * @msg_hdr: 32-bit pa
On 09/02/2022 13:48, Anthony PERARD wrote:
> On Wed, Feb 09, 2022 at 12:26:05PM +, Jane Malalane wrote:
>> On 08/02/2022 15:26, Roger Pau Monné wrote:
>>> On Mon, Feb 07, 2022 at 06:21:00PM +, Jane Malalane wrote:
diff --git a/tools/golang/xenlight/types.gen.go
b/tools/golang/xen
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, 9 February 2022 16:23
> To: dinhngoc...@irit.fr
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2] x86: Use low memory size directly from Multiboot
>
> On 09.02.2022 16:20, dinhngoc...@irit.fr wrote:
> > This change s
On Wed, Feb 09, 2022 at 02:12:51PM +0100, Tu Dinh Ngoc wrote:
> Previously, Xen used information from the BDA to detect the amount of
> available low memory. This does not work on some scenarios such as
> Coreboot, or when booting from Kexec on a UEFI system without CSM.
>
> Use the information di
On 09.02.22 13:04, Jan Beulich wrote:
Hi Jan
> On 09.02.2022 11:08, Oleksandr Tyshchenko wrote:
>> On 08.02.22 14:47, Jan Beulich wrote:
>>
>>
>> Hi Julien, Jan
>>
>>
>>> On 08.02.2022 12:58, Julien Grall wrote:
On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
> On 07.02.22 19:15, Juli
flight 168070 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168070/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 09/02/2022 11:37, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 09.02.2022 11:31, Jane Malalane wrote:
>> This is not a bug. The xen cmdline can request both a NUMA restr
flight 168062 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168062/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168014
test-armhf-armhf-libvirt 16
From: Jan Beulich
[ Upstream commit e25a8d959992f61b64a58fc62fb7951dc6f31d1f ]
This started out with me noticing that "dom0_max_vcpus=" with
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s. Addressing this is the primary
purpose of the
From: Jan Beulich
[ Upstream commit e25a8d959992f61b64a58fc62fb7951dc6f31d1f ]
This started out with me noticing that "dom0_max_vcpus=" with
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s. Addressing this is the primary
purpose of the
From: Jan Beulich
[ Upstream commit e25a8d959992f61b64a58fc62fb7951dc6f31d1f ]
This started out with me noticing that "dom0_max_vcpus=" with
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s. Addressing this is the primary
purpose of the
On Wed, Feb 09, 2022 at 12:17:17PM +, Julien Grall wrote:
> > > > +static HYPFS_DIR_INIT_FUNC(host_dt_dir, HOST_DT_DIR,
> > > > &host_dt_dir_funcs);
> > > > +
> > > > +static int __init host_dtb_export_init(void)
> > > > +{
> > > > +ASSERT(dt_host && (dt_host->sibling == NULL));
> > >
> >
flight 168061 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168061/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 168013
test-amd64-amd64-xl-qemut-win7-a
flight 168067 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi,
On 09/02/2022 18:51, Oleksii Moisieiev wrote:
On Wed, Feb 09, 2022 at 12:17:17PM +, Julien Grall wrote:
+static HYPFS_DIR_INIT_FUNC(host_dt_dir, HOST_DT_DIR, &host_dt_dir_funcs);
+
+static int __init host_dtb_export_init(void)
+{
+ASSERT(dt_host && (dt_host->sibling == NULL));
dt_
flight 168071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 168066 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168066/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168052
test-amd64-amd64-qemuu-nested-amd 20
flight 168069 xen-unstable real [real]
flight 168073 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168069/
http://logs.test-lab.xenproject.org/osstest/logs/168073/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 168074 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168074/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c9b7c6e0cc7da76b74bcdd8c90cef956d5ae971c
baseline version:
ovmf b360b0b589697da267f5d
flight 168072 linux-linus real [real]
flight 168077 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168072/
http://logs.test-lab.xenproject.org/osstest/logs/168077/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
Hi Jan,
Thanks for letting me know this status.
I am wondering if PCI passthrough is at least available in Arm for other
virtualization modes like PV, HVM, or PVHVM. For example, is it possible for
someone to attach a PCI device to a guest domain on an Arm machine and use that
domain as a driv
On 10.02.2022 08:22, tosher 1 wrote:
> I am wondering if PCI passthrough is at least available in Arm for other
> virtualization modes like PV, HVM, or PVHVM. For example, is it possible for
> someone to attach a PCI device to a guest domain on an Arm machine and use
> that domain as a driver do
On 08.02.22 19:00, Oleksii Moisieiev wrote:
Nit: in the patch title s/fo/for/
Add new api:
- hypfs_read_dyndir_entry
- hypfs_gen_dyndir_entry
which are the extension of the dynamic hypfs nodes support, presented in
0b3b53be8cf226d947a79c2535a9efbb2dd7bc38.
This allows nested dynamic nodes to be
70 matches
Mail list logo
