On 2025/1/27 22:52, Jan Beulich wrote:
> On 27.01.2025 15:41, Roger Pau Monné wrote:
>> On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote:
>>> On 23.01.2025 04:50, Jiqian Chen wrote:
v5->v6 changes:
* Changed "1UL" to "1ULL" in PCI_REBAR_CTRL_SIZE idefinition for 32 bit
ar
Sean Christopherson writes:
> On Tue, Feb 04, 2025, Nikunj A Dadhania wrote:
>> Sean Christopherson writes:
>>
>> > When running as a TDX guest, explicitly override the TSC frequency
>> > calibration routine with CPUID-based calibration instead of potentially
>> > relying on a hypervisor-contro
On 2025/1/27 23:08, Roger Pau Monné wrote:
> On Mon, Jan 27, 2025 at 03:52:31PM +0100, Jan Beulich wrote:
>> On 27.01.2025 15:41, Roger Pau Monné wrote:
>>> On Mon, Jan 27, 2025 at 03:20:40PM +0100, Jan Beulich wrote:
On 23.01.2025 04:50, Jiqian Chen wrote:
> v5->v6 changes:
> * Change
Hi all,
I would like to propose to enable the UBSAN config option in our Gitlab
pipelines. The attached patch (just for testing, do not commit) enables
UBSAN on the Xen build jobs used for most of the ARM and x86 tests. The
pipeline passes.
https://gitlab.com/xen-project/people/sstabellini/xen/-/
On Tue, 4 Feb 2025, Teddy Astie wrote:
> Hello Stefano,
>
> Le 03/02/2025 à 18:47, Stefano Stabellini a écrit :
> > On Mon, 3 Feb 2025, Teddy Astie wrote:
> >> Hello Jason,
> >>
> >> Le 30/01/2025 à 21:17, Jason Andryuk a écrit :
> >>> Hi Teddy,
> >>>
> >>> Thanks for working on this. I'm curious
Am 4. Februar 2025 21:25:46 UTC schrieb "Philippe Mathieu-Daudé"
:
>Hi Bernhard,
>
>On 27/1/25 10:46, Bernhard Beschow wrote:
>> Am 25. Januar 2025 18:13:43 UTC schrieb "Philippe Mathieu-Daudé"
>> :
>>> Because the legacy Xen backend devices can optionally be plugged on the
>>> TYPE_PLATFORM_B
Hi Stefano,
On Tue, 4 Feb 2025 at 17:57, Stefano Stabellini
wrote:
> On Tue, 4 Feb 2025, Julien Grall wrote:
> > On Tue, 4 Feb 2025 at 11:46, Teddy Astie wrote:
> > If the hardware supports it, there is a alternative (still being
> > drafted) interface to allow the guest to directl
Hi Bernhard,
On 27/1/25 10:46, Bernhard Beschow wrote:
Am 25. Januar 2025 18:13:43 UTC schrieb "Philippe Mathieu-Daudé"
:
Because the legacy Xen backend devices can optionally be plugged on the
TYPE_PLATFORM_BUS_DEVICE, have it inherit TYPE_DYNAMIC_SYS_BUS_DEVICE.
Remove the implicit TYPE_XENS
On 27/1/25 10:41, Bernhard Beschow wrote:
Makes the code less sensitive regarding changes in the class hierarchy which
will be performed in the next patch.
Signed-off-by: Bernhard Beschow
---
hw/usb/xen-usb.c| 6 +++---
hw/xen/xen-legacy-backend.c | 2 +-
hw/xen/xen_pvdev.c
On Tue, 4 Feb 2025, Julien Grall wrote:
> On Tue, 4 Feb 2025 at 11:46, Teddy Astie wrote:
> If the hardware supports it, there is a alternative (still being
> drafted) interface to allow the guest to directly provide native
> pagetables.
>
> This is exposed through the "_nested
On Tue, Feb 04, 2025, Nikunj A Dadhania wrote:
> Sean Christopherson writes:
>
> > When running as a TDX guest, explicitly override the TSC frequency
> > calibration routine with CPUID-based calibration instead of potentially
> > relying on a hypervisor-controlled PV routine. For TDX guests, CPU
Enabled early booting of R52.
Ayan Kumar Halder (5):
xen/arm: mpu: Ensure that the page size is 4KB (arm32)
xen/arm: mpu: Enclose access to MMU specific registers under
CONFIG_MMU (arm32)
xen/arm: mpu: Move some of the definitions to common file
xen/arm: mpu: Create boot-time MPU prote
Define enable_boot_cpu_mm() for the Armv8-R AArch64.
Like boot-time page table in MMU system, we need a boot-time MPU protection
region configuration in MPU system so Xen can fetch code and data from normal
memory.
To do this, Xen maps the following sections of the binary as separate regions
(wit
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm32/mpu/head.S | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/arm/arm32/mpu/head.S b/xe
All the EL2 MMU specific registers in head.S are enclosed within CONFIG_MMU.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm32/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 4ff5c220bc..1d0f84b18f 100644
--- a/xen/ar
For AArch32, refer to ARM DDI 0568A.c ID110520.
MPU_REGION_SHIFT is same between AArch32 and AArch64 (HPRBAR).
Also, NUM_MPU_REGIONS_SHIFT is same between AArch32 and AArch64
(HMPUIR).
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm64/mpu/head.S | 2 +-
xen/arch/arm/include/as
Similar to "xen/arm: mpu: Define Xen start address for MPU systems", added
a build assertion to ensure that the page size is 4KB.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm32/Makefile | 1 +
xen/arch/arm/arm32/mpu/Makefile | 1 +
xen/arch/arm/arm32/mpu/mm.c | 15
On Tue, Feb 4, 2025 at 4:20 PM Andrew Cooper wrote:
>
> On 22/01/2025 10:14 am, Frediano Ziglio wrote:
> > Although code is compiled with -fpic option data is not position
> > independent.
>
> This doesn't parse. ITYM "Although the code is compiled with -fpic,
> pointers in data are not position
On 03/02/2025 8:58 am, Guillaume wrote:
> Oh cool, thanks a lot for the explanation.
> I added the "vzeroupper" and Xen crashes so it looks like the CPUID
> emulation is buggy. Also I was able to try it using a VM (same debian
> testing) running on virt-manager+kvm and it works fine (Xen in debug
>
v2->v3:
* Moved "extern uint32_t *cpu_to_apicid;" to patch1
v2:
https://lore.kernel.org/xen-devel/20250204144542.7399-1-alejandro.vall...@cloud.com/T/#t
v1->v2:
* Dropped patch to skip writing the MP Tables if apicid >= 255
v1:
https://lore.kernel.org/xen-devel/20250128163342.1491-1-alejand
Replace uses of the LAPIC_ID() macro with accesses to the
cpu_to_apicid[] lookup table. This table contains the APIC IDs of each
vCPU as probed at runtime rather than assuming a predefined relation.
Moved smp_initialise() ahead of apic_setup() in order to initialise
cpu_to_apicid ASAP and avoid us
Make it so the APs expose their own APIC IDs in a lookup table (LUT). We
can use that LUT to populate the MADT, decoupling the algorithm that
relates CPU IDs and APIC IDs from hvmloader.
Modified the printf to also print the APIC ID of each CPU, as well as
fixing a (benign) wrong specifier being u
On Tue Feb 4, 2025 at 3:46 PM GMT, Jan Beulich wrote:
> On 04.02.2025 16:25, Alejandro Vallejo wrote:
> > On Tue Feb 4, 2025 at 3:07 PM GMT, Jan Beulich wrote:
> >> On 04.02.2025 15:45, Alejandro Vallejo wrote:
> >>> --- a/tools/firmware/hvmloader/config.h
> >>> +++ b/tools/firmware/hvmloader/confi
On 22/01/2025 10:14 am, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent.
This doesn't parse. ITYM "Although the code is compiled with -fpic,
pointers in data are not position independent."
> This causes data pointer to become invalid if
>
From: Stewart Hildebrand
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". We rely on dom0 to initialize the PCI controller
and perform a PHYSDEVOP_pci_device_add call to add each device to SMMU.
Enable pci_init() for initializing Xen's internal PCI subsystem
On Tue, 4 Feb 2025 at 11:46, Teddy Astie wrote:
> If the hardware supports it, there is a alternative (still being
> drafted) interface to allow the guest to directly provide native
> pagetables.
>
> This is exposed through the "_nested" subcommands, there is no
> implementation of this feature i
On 04.02.2025 16:25, Alejandro Vallejo wrote:
> On Tue Feb 4, 2025 at 3:07 PM GMT, Jan Beulich wrote:
>> On 04.02.2025 15:45, Alejandro Vallejo wrote:
>>> --- a/tools/firmware/hvmloader/config.h
>>> +++ b/tools/firmware/hvmloader/config.h
>>> @@ -48,8 +48,9 @@ extern uint8_t ioapic_version;
>>>
>
On 2025-02-04 06:13, Jan Beulich wrote:
On 26.12.2024 17:57, Daniel P. Smith wrote:
Introduce the ability to assign capabilities to a domain via its definition in
device tree. The first capability enabled to select is the control domain
capability.
Hmm, and not at the same time another one to
On Tue Feb 4, 2025 at 3:07 PM GMT, Jan Beulich wrote:
> On 04.02.2025 15:45, Alejandro Vallejo wrote:
> > --- a/tools/firmware/hvmloader/config.h
> > +++ b/tools/firmware/hvmloader/config.h
> > @@ -48,8 +48,9 @@ extern uint8_t ioapic_version;
> >
> > #define IOAPIC_ID 0x01
> >
> > +e
On 04.02.2025 15:45, Alejandro Vallejo wrote:
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -48,8 +48,9 @@ extern uint8_t ioapic_version;
>
> #define IOAPIC_ID 0x01
>
> +extern uint32_t *cpu_to_apicid;
Strictly speaking this ought to be par
On 03.02.2025 14:12, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -55,6 +55,22 @@
> #define PTE_SMALL BIT(10, UL)
> #define PTE_POPULATEBIT(11, UL)
>
> +/*
> + * In the case when modifying or destroying a mapping, it
Hello Stefano,
Le 03/02/2025 à 18:47, Stefano Stabellini a écrit :
> On Mon, 3 Feb 2025, Teddy Astie wrote:
>> Hello Jason,
>>
>> Le 30/01/2025 à 21:17, Jason Andryuk a écrit :
>>> Hi Teddy,
>>>
>>> Thanks for working on this. I'm curious about your plans for this:
>>>
>>> On 2025-01-21 11:13, Te
Make it so the APs expose their own APIC IDs in a lookup table (LUT). We
can use that LUT to populate the MADT, decoupling the algorithm that
relates CPU IDs and APIC IDs from hvmloader.
Modified the printf to also print the APIC ID of each CPU, as well as
fixing a (benign) wrong specifier being u
v1->v2:
* Dropped patch to skip writing the MP Tables if apicid >= 255
v1:
https://lore.kernel.org/xen-devel/20250128163342.1491-1-alejandro.vall...@cloud.com/
source series:
https://lore.kernel.org/xen-devel/20241021154600.11745-5-alejandro.vall...@cloud.com/
The hypervisor, hvmloader and th
Replace uses of the LAPIC_ID() macro with accesses to the
cpu_to_apicid[] lookup table. This table contains the APIC IDs of each
vCPU as probed at runtime rather than assuming a predefined relation.
Moved smp_initialise() ahead of apic_setup() in order to initialise
cpu_to_apicid ASAP and avoid us
On 04.02.2025 14:54, Mykyta Poturai wrote:
> From: Stewart Hildebrand
>
> Enable the use of IOMMU + PCI in dom0 without having to specify
> "pci-passthrough=yes". We rely on dom0 to initialize the PCI controller
> and perform a PHYSDEVOP_pci_device_add call to add each device to SMMU.
>
> Enable
On Thu Jan 30, 2025 at 9:17 AM GMT, Jan Beulich wrote:
> On 29.01.2025 17:25, Roger Pau Monné wrote:
> > On Tue, Jan 28, 2025 at 06:42:38PM +, Alejandro Vallejo wrote:
> >> On Tue Jan 28, 2025 at 5:45 PM GMT, Roger Pau Monné wrote:
> >>> On Tue, Jan 28, 2025 at 04:33:39PM +, Alejandro Valle
On 04.02.2025 14:54, Mykyta Poturai wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
Please insert where the other xen/ #include-s are. (Those aren't sorted
yet, so there is more than one pla
On 04.02.2025 14:54, Mykyta Poturai wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -238,6 +238,9 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct
> domain *d,
> */
> int iommu_remove_dt_device(struct dt_device_node *np);
>
> +/* Error code for reporting
From: Oleksandr Tyshchenko
Move code for processing DT IOMMU specifier to a separate helper.
This helper will be re-used for adding PCI devices by the subsequent
patches as we will need exact the same actions for processing
DT PCI-IOMMU specifier.
While at it introduce NO_IOMMU to avoid magic "1
On 04.02.2025 14:56, Andrew Cooper wrote:
> On 04/02/2025 1:19 pm, Jan Beulich wrote:
>> On 04.02.2025 14:10, Andrew Cooper wrote:
>>> On 04/02/2025 1:03 pm, Jan Beulich wrote:
--- a/xen/include/xen/radix-tree.h
+++ b/xen/include/xen/radix-tree.h
@@ -72,6 +72,9 @@ struct radix_tree_r
On 03.02.2025 14:12, Oleksii Kurochko wrote:
> @@ -160,6 +158,18 @@ static inline struct page_info *virt_to_page(const void
> *v)
>
> pte_t * pt_walk(vaddr_t va, unsigned int *pte_level);
>
> +static inline mfn_t vmap_to_mfn_(vaddr_t va)
Btw., for static functions (and variables) a prefixing
On 04/02/2025 1:19 pm, Jan Beulich wrote:
> On 04.02.2025 14:10, Andrew Cooper wrote:
>> On 04/02/2025 1:03 pm, Jan Beulich wrote:
>>> --- a/xen/include/xen/radix-tree.h
>>> +++ b/xen/include/xen/radix-tree.h
>>> @@ -72,6 +72,9 @@ struct radix_tree_root {
>>> *** radix-tree API starts here **
>>>
This series introduces SMMU handling for PCIe passthrough on ARM. These patches
should be able to be upstreamed independently from the vPCI series [1]. See [2]
for notes about test cases.
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.html
[2] https://lists.xenproject.or
From: Rahul Singh
Current code skip the mapping for PCI bridge MMIO region to dom0 when
pci_passthrough_enabled flag is set. Mapping should be skip when
has_vpci(d) is enabled for the domain, as we need to skip the mapping
only when VPCI handler are registered for ECAM.
Signed-off-by: Rahul Sing
From: Rahul Singh
When ITS is enabled and PCI devices that are behind an SMMU generate an
MSI interrupt, SMMU fault will be observed as there is currently no
mapping in p2m table for the ITS translation register (GITS_TRANSLATER).
A mapping is required in the iommu page tables so that the device
From: Oleksandr Andrushchenko
Implement support for PCI devices in the SMMU driver. Make arm_smmu_master
structure to hold a pointer to the device to allow it to hold PCI devices.
Trigger iommu-map parsing when new PCI device is added. Add checks to
assign/deassign functions to ensure PCI devices
From: Oleksandr Tyshchenko
The main purpose of this patch is to add a way to register PCI device
(which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
before assigning that device to a domain.
This behaves similarly to the existing iommu_add_dt_device API, except it
handles PCI
From: Rahul Singh
Implement support for PCI devices in the SMMU driver. Trigger iommu-map
parsing when new PCI device is added. Add checks to assign/deassign
functions to ensure PCI devices are handled correctly. Implement basic
quarantining.
All pci devices are automatically assigned to hardwar
From: Stewart Hildebrand
Handle phantom functions in iommu_add_dt_pci_sideband_ids(). Each phantom
function will have a unique requestor ID (RID)/BDF. On ARM, we need to
map/translate the RID/BDF to an AXI stream ID for each phantom function
according to the pci-iommu device tree mapping [1]. The
On 03.02.2025 14:12, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -156,6 +156,10 @@ static inline struct page_info *virt_to_page(const void
> *v)
> return frametable_virt_start + PFN_DOWN(va - directmap_virt_start);
> }
>
> +#
On 04.02.2025 12:46, Roger Pau Monné wrote:
> On Wed, Jan 29, 2025 at 11:13:09AM +0100, Jan Beulich wrote:
>> On 28.01.2025 17:27, Roger Pau Monne wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1803,6 +1803,38 @@ int iommu_do_pci_domctl(
>>> retu
On 04.02.2025 14:10, Andrew Cooper wrote:
> On 04/02/2025 1:03 pm, Jan Beulich wrote:
>> --- a/xen/include/xen/radix-tree.h
>> +++ b/xen/include/xen/radix-tree.h
>> @@ -72,6 +72,9 @@ struct radix_tree_root {
>> *** radix-tree API starts here **
>> */
>>
>> +#define RADIX_TREE_INIT() {}
>> +#d
They aren't used anymore.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/common/radix-tree.c
+++ b/xen/common/radix-tree.c
@@ -60,16 +60,14 @@ static void cf_check _rcu_node_free(stru
xfree(rcu_node);
}
-static struct radix_tree_node *radix_tree_node_alloc(
On 04/02/2025 1:03 pm, Jan Beulich wrote:
> ... now that static initialization is possible. Use RADIX_TREE() for
> pci_segments and ivrs_maps.
>
> This then fixes an ordering issue on x86: With the call to
> radix_tree_init(), acpi_mmcfg_init()'s invocation of pci_segments_init()
> will zap the pos
On 22.01.2025 11:14, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent. This causes data pointer to become invalid if
> code is not relocated properly which is what happens for
> efi_multiboot2 which is called by multiboot entry code.
>
> Code
Have callers invoke pci_add_segment() directly instead: With radix tree
initialization moved out of the function, its name isn't quite
describing anymore what it actually does.
Signed-off-by: Jan Beulich
---
This is entirely optional and up for discussion. There certainly also is
an argument towa
... now that static initialization is possible. Use RADIX_TREE() for
pci_segments and ivrs_maps.
This then fixes an ordering issue on x86: With the call to
radix_tree_init(), acpi_mmcfg_init()'s invocation of pci_segments_init()
will zap the possible earlier introduction of segment 0 by
amd_iommu_
These were needed by TMEM only, which is long gone. The Linux original
doesn't have such either. This effectively reverts one of the "Other
changes" from 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux
to gain RCU awareness").
Positive side effect: Two cf_check go away.
While there also
What previously was the main bug fix in this series was dropped for v3. It
turns out what is now patch 2 is sufficient to address the issue, while
doing the requested tidying. The latter two patches are for 4.21 only, with
the final one being up for debate altogether.
1: radix-tree: purge node all
On 04.02.2025 08:20, Oleksii Kurochko wrote:
> +/*
> + * The canonical order of ISA extension names in the ISA string is defined in
> + * chapter 27 of the unprivileged specification.
> + *
> + * The specification uses vague wording, such as should, when it comes to
> + * ordering, so for our purpo
On Wed, Jan 29, 2025 at 11:13:09AM +0100, Jan Beulich wrote:
> On 28.01.2025 17:27, Roger Pau Monne wrote:
> > The current shutdown logic in smp_send_stop() will first disable the APs,
> > and then attempt to disable (some) of the interrupt sources.
> >
> > There are two issues with this approach;
Instead of checking each known domain after having received a
VIRQ_DOM_EXC event, use the new xenmanage_poll_changed_domain()
function for directly getting the domid of a domain having changed
its state.
A test doing "xl shutdown" of 1000 guests has shown to reduce the
consumed cpu time of xenstor
Use the new unique_id of a domain in order to detect that a domain
has been replaced with another one reusing the doamin-id of the old
domain.
Signed-off-by: Juergen Gross
---
V8:
- new patch
---
tools/xenstored/domain.c | 53 +++-
tools/xenstored/xenstore_sta
In order to close a race window for Xenstore live update when using
the new unique_id of domains, the migration stream needs to contain
this unique_id for each domain known by Xenstore.
Signed-off-by: Juergen Gross
---
V8:
- new patch
---
docs/designs/xenstore-migration.md | 14 +-
1
Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.
This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.
For now only do a direc
Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).
The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).
In order to enable Xenstore stubdom being built for multiple Xen
versions, make th
XEN_DOMCTL_set_virq_handler will happily steal a global virq from the
current domain having bound it and assign it to another domain. The
former domain will just never receive any further events for that
virq without knowing what happened.
Change the behavior to allow XEN_DOMCTL_set_virq_handler o
In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.
Signed-off-by: Juergen Gross
Reviewed-by: Anthony PERARD
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in heade
Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).
Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.
As the usage of this bitmap i
Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.
This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.
There was a RFC series sent out 3 years ago, which I have taken as a
base and
Today Xen will happily allow binding a global virq by a domain which
isn't configured to receive it. This won't result in any bad actions,
but the bind will appear to have succeeded with no event ever being
received by that event channel.
Instead of allowing the bind, error out if the domain isn't
Hi there,
On 31/01/25 5:35 PM, Harshvardhan Jha wrote:
> On 30/01/25 6:05 PM, Jürgen Groß wrote:
>> On 29.01.25 19:46, Harshvardhan Jha wrote:
>>> On 30/01/25 12:13 AM, Jürgen Groß wrote:
On 29.01.25 19:35, Harshvardhan Jha wrote:
> On 29/01/25 4:52 PM, Juergen Gross wrote:
>> On 29.0
On 04/02/2025 8:36 am, Jan Beulich wrote:
> On 03.02.2025 17:58, Jan Beulich wrote:
>> On 03.02.2025 17:48, Andrew Cooper wrote:
>>> On 03/02/2025 4:26 pm, Jan Beulich wrote:
... now that static initialization is possible. Use RADIX_TREE() for
pci_segments and ivrs_maps.
Request
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Introduce the ability to assign capabilities to a domain via its definition in
> device tree. The first capability enabled to select is the control domain
> capability.
Hmm, and not at the same time another one to select "hardware domain"?
> --- a/xen
Hi Jan,
On 4/2/25 10:11, Jan Beulich wrote:
On 04.02.2025 09:19, Juergen Gross wrote:
On 03.02.25 23:43, Stefano Stabellini wrote:
+Xen maintainers
On Mon, 3 Feb 2025, Richard Henderson wrote:
On 2/3/25 04:54, Paolo Bonzini wrote:
On 2/3/25 04:18, Richard Henderson wrote:
v1: 202501280042
Sean Christopherson writes:
> When running as a TDX guest, explicitly override the TSC frequency
> calibration routine with CPUID-based calibration instead of potentially
> relying on a hypervisor-controlled PV routine. For TDX guests, CPUID.0x15
> is always emulated by the TDX-Module, i.e. the
On 04.02.2025 09:56, Roger Pau Monné wrote:
> On Tue, Feb 04, 2025 at 08:51:10AM +0100, Jan Beulich wrote:
>> On 04.02.2025 08:45, Jan Beulich wrote:
>>> On 03.02.2025 18:18, Roger Pau Monné wrote:
On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/mmc
On 04.02.2025 09:19, Juergen Gross wrote:
> On 03.02.25 23:43, Stefano Stabellini wrote:
>> +Xen maintainers
>>
>>
>> On Mon, 3 Feb 2025, Richard Henderson wrote:
>>> On 2/3/25 04:54, Paolo Bonzini wrote:
On 2/3/25 04:18, Richard Henderson wrote:
> v1: 20250128004254.33442-1-richard.hender
On Tue, Feb 04, 2025 at 08:51:10AM +0100, Jan Beulich wrote:
> On 04.02.2025 08:45, Jan Beulich wrote:
> > On 03.02.2025 18:18, Roger Pau Monné wrote:
> >> On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
> >>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
> >>> +++ b/xen/arch/x86/x86_64/
On 04.02.2025 09:36, Jan Beulich wrote:
> On 03.02.2025 17:58, Jan Beulich wrote:
>> On 03.02.2025 17:48, Andrew Cooper wrote:
>>> On 03/02/2025 4:26 pm, Jan Beulich wrote:
... now that static initialization is possible. Use RADIX_TREE() for
pci_segments and ivrs_maps.
Requested
On 03.02.2025 17:58, Jan Beulich wrote:
> On 03.02.2025 17:48, Andrew Cooper wrote:
>> On 03/02/2025 4:26 pm, Jan Beulich wrote:
>>> ... now that static initialization is possible. Use RADIX_TREE() for
>>> pci_segments and ivrs_maps.
>>>
>>> Requested-by: Andrew Cooper
>>> Signed-off-by: Jan Beuli
Sean Christopherson writes:
> Move the check on having a Secure TSC to the common tsc_early_init() so
> that it's obvious that having a Secure TSC is conditional, and to prepare
> for adding TDX to the mix (blindly initializing *both* SNP and TDX TSC
> logic looks especially weird).
Agree.
>
>
On 03.02.25 23:43, Stefano Stabellini wrote:
+Xen maintainers
On Mon, 3 Feb 2025, Richard Henderson wrote:
On 2/3/25 04:54, Paolo Bonzini wrote:
On 2/3/25 04:18, Richard Henderson wrote:
v1: 20250128004254.33442-1-richard.hender...@linaro.org
For v2, immediately disable 64-on-32 TCG.
I *su
On Mon, Feb 03, 2025 at 02:43:05PM -0800, Stefano Stabellini wrote:
> +Xen maintainers
>
>
> On Mon, 3 Feb 2025, Richard Henderson wrote:
> > On 2/3/25 04:54, Paolo Bonzini wrote:
> > > On 2/3/25 04:18, Richard Henderson wrote:
> > > > v1: 20250128004254.33442-1-richard.hender...@linaro.org
> > >
Sean Christopherson writes:
> Move the code to mark the TSC as reliable from sme_early_init() to
> snp_secure_tsc_init(). The only reader of TSC_RELIABLE is the aptly
> named check_system_tsc_reliable(), which runs in tsc_init(), i.e.
> after snp_secure_tsc_init().
>
> This will allow consolidat
86 matches
Mail list logo
