Hi Ayan,
> On 27 Feb 2025, at 20:29, Ayan Kumar Halder wrote:
>
>
> On 27/02/2025 17:15, Bertrand Marquis wrote:
>> Hi Ayan,
>
> Hi Bertrand,
>
> I have just some clarifications.
>
>>
>>> On 27 Feb 2025, at 16:09, Ayan Kumar Halder
>>> wrote:
>>>
>>> In the current patch, we have defined
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, February 27, 2025 12:08 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andryuk, Jason
> ; Andrew Cooper ;
> Roger Pau Monné ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2 08/11] xen/cpufreq: abstract Energy Per
On Thu, Feb 27, 2025 at 03:33:18PM +, Teddy Astie wrote:
> Hello,
>
> Le 27/02/2025 à 13:57, Xen.org security team a écrit :
> > Xen Security Advisory CVE-2025-1713 / XSA-467
> >
> > deadlock potential with VT-d and legacy PCI device pass-through
> >
> > ISSUE DESCRIPTION
> >
On 15/11/2024 9:28 am, Jan Beulich wrote:
> On 14.11.2024 19:22, Andrew Cooper wrote:
>> It may have taken a while, but it occurs to me that the mentioned commit
>> fixed
>> a second problem too.
>>
>> On entering trampoline_boot_cpu_entry(), %esp points at the trampoline stack,
>> but in a 32bit
On 27/02/25 18:35, Mark Rutland wrote:
> On Thu, Feb 27, 2025 at 07:08:56PM +0100, Valentin Schneider wrote:
>> On 13/02/25 21:00, Jinjie Ruan wrote:
>> > Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
>> > to use the generic entry infrastructure from kernel/entry/*.
>> > The
I've raised this during review before, but:
> (XEN) [ 1.209230] AMD-Vi: IOMMU Extended Features:
> (XEN) [ 1.213998] - Peripheral Page Service Request
> (XEN) [ 1.218849] - x2APIC
> (XEN) [ 1.221536] - NX bit
> (XEN) [ 1.224221] - Invalidate All Command
> (XEN) [ 1.228297] - Gues
On 2025-02-27 05:23, Roger Pau Monné wrote:
On Wed, Feb 26, 2025 at 04:11:25PM -0500, Jason Andryuk wrote:
Sometimes we have to quirk the PCI IRTE to use a non-zero remap_index
corresponding to the guest's view of the MSI data register. The MSI
data guest vector equals interrupt remapping table
On 27/02/2025 17:15, Bertrand Marquis wrote:
Hi Ayan,
Hi Bertrand,
I have just some clarifications.
On 27 Feb 2025, at 16:09, Ayan Kumar Halder wrote:
In the current patch, we have defined the requirements which are common for
all the commands.
Signed-off-by: Ayan Kumar Halder
---
Ch
On 27/02/2025 6:28 pm, Jason Andryuk wrote:
> On 2025-02-27 05:23, Roger Pau Monné wrote:
>>> To work around this, we can, for per-device IRTs, program the hardware
>>> to use the guest data & associated IRTE. The address doesn't matter
>>> since the IRTE handles that, and the Xen address & vector
On Thu, Feb 27, 2025 at 07:08:56PM +0100, Valentin Schneider wrote:
> On 13/02/25 21:00, Jinjie Ruan wrote:
> > Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
> > to use the generic entry infrastructure from kernel/entry/*.
> > The generic entry makes maintainers' work easier
Hi Ayan,
> On 27 Feb 2025, at 16:09, Ayan Kumar Halder wrote:
>
> In the current patch, we have defined the requirements which are common for
> all the commands.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from -
>
> v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen do
On 13/02/25 21:00, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
> to use the generic entry infrastructure from kernel/entry/*.
> The generic entry makes maintainers' work easier and codes
> more elegant.
>
> Switch arm64 to generic IRQ entry first, whic
On 2/27/25 01:58, Jan Beulich wrote:
> On 26.02.2025 20:57, Stewart Hildebrand wrote:
>> On 2/26/25 06:38, Jan Beulich wrote:
>>> 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
Hello,
Le 27/02/2025 à 13:57, Xen.org security team a écrit :
> Xen Security Advisory CVE-2025-1713 / XSA-467
>
> deadlock potential with VT-d and legacy PCI device pass-through
>
> ISSUE DESCRIPTION
> =
>
> When setting up interrupt remapping for legacy PCI(-X) d
Hi Ayan,
> On 27 Feb 2025, at 16:09, Ayan Kumar Halder wrote:
>
> We have written the requirements for some of the commands of the XEN_VERSION
> hypercall.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> Changes from -
>
> v1 - 1. Reworded the requirement so as to avoid mentioining variable name
On 2025-02-27 03:54, Jan Beulich wrote:
On 26.02.2025 22:11, Jason Andryuk wrote:
Sometimes we have to quirk the PCI IRTE to use a non-zero remap_index
corresponding to the guest's view of the MSI data register. The MSI
data guest vector equals interrupt remapping table index.
The ath11k wifi
On 2025-02-26 22:36, Chen, Jiqian wrote:
On 2025/2/27 04:01, Jason Andryuk wrote:
@@ -475,14 +478,14 @@ static int pcistub_init_device(struct pcistub_device
*psdev)
#ifdef CONFIG_XEN_ACPI
if (xen_initial_domain() && xen_pvh_domain()) {
err = xen_acpi_get_gsi_info(dev,
On 27/02/2025 2:50 pm, Frediano Ziglio wrote:
> On XenServer on Windows machine a platform device with ID 2 instead of
> 1 is used.
>
> This device is mainly identical to device 1 but due to some Windows
> update behaviour it was decided to use a device with a different ID.
>
> This causes compatib
On 2025-02-27 03:23, Jan Beulich wrote:
On 26.02.2025 21:01, Jason Andryuk wrote:
--- a/drivers/xen/acpi.c
+++ b/drivers/xen/acpi.c
@@ -101,7 +101,7 @@ int xen_acpi_get_gsi_info(struct pci_dev *dev,
pin = dev->pin;
if (!pin)
- return -EINVAL;
+ return
On 2025-02-27 03:25, Jan Beulich wrote:
On 26.02.2025 21:10, Jason Andryuk wrote:
--- a/tools/libs/light/libxl_x86.c
+++ b/tools/libs/light/libxl_x86.c
@@ -925,7 +928,10 @@ int libxl__arch_hvm_unmap_gsi(libxl__gc *gc, uint32_t
sbdf, uint32_t domid)
int pirq = -1, gsi, r;
gsi =
On 27.02.25 15:50, Frediano Ziglio wrote:
On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.
This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.
This causes compatibility issues w
In the current patch, we have defined the requirements which are common for
all the commands.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not return
0 for success in all the cases.
2. Reworded the requirements so as to
On 26.02.25 16:55, Anthony PERARD wrote:
On Tue, Feb 25, 2025 at 08:30:33AM +0100, Juergen Gross wrote:
Channels work differently than other device types: their devid should
be -1 initially in order to distinguish them from the primary console
which has the devid of 0.
So when parsing the chann
We have written the requirements for some of the commands of the XEN_VERSION
hypercall.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Reworded the requirement so as to avoid mentioining variable names
or hardcoded strings. Otherwise, one would need to change the requirement
each ti
On Wed Feb 26, 2025 at 2:02 PM GMT, Jan Beulich wrote:
> On 24.02.2025 14:27, Alejandro Vallejo wrote:
> > @@ -504,17 +502,16 @@ unsigned long domain_adjust_tot_pages(struct domain
> > *d, long pages)
> > goto out;
> >
> > spin_lock(&heap_lock);
> > -/* adjust domain outstandin
On Wed Feb 26, 2025 at 4:51 PM GMT, Andrew Cooper wrote:
> On 26/02/2025 4:42 pm, Jan Beulich wrote:
> > On 26.02.2025 17:34, Andrew Cooper wrote:
> >> On 26/02/2025 4:06 pm, Jan Beulich wrote:
> >>> On 26.02.2025 17:04, Roger Pau Monné wrote:
> On Wed, Feb 26, 2025 at 03:36:33PM +0100, Jan Be
On Wed Feb 26, 2025 at 2:28 PM GMT, Roger Pau Monné wrote:
> On Wed, Feb 26, 2025 at 03:08:33PM +0100, Jan Beulich wrote:
> > On 26.02.2025 14:56, Roger Pau Monné wrote:
> > > On Mon, Feb 24, 2025 at 01:27:24PM +, Alejandro Vallejo wrote:
> > >> --- a/xen/common/page_alloc.c
> > >> +++ b/xen/co
On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.
This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.
This causes compatibility issues with Linux which expects, if Xen
is detected,
Signed-off-by: Oleksii Kurochko
---
Changes in v3:
- Update that CONFIG_UBSAN is also enabled for PPC; also for the same item
change Arm to Arm64.
- Add "Intel EPT" to "Add suport for Paging-Write Feature"; drop "Add" at
the start as it is already in Added section.
- "Zen 5" change to "AM
On Wed Feb 26, 2025 at 2:05 PM GMT, Jan Beulich wrote:
> On 24.02.2025 15:49, Alejandro Vallejo wrote:
> > Open question to whoever reviews this...
> >
> > On Mon Feb 24, 2025 at 1:27 PM GMT, Alejandro Vallejo wrote:
> >> spin_lock(&heap_lock);
> >> -/* adjust domain outstanding pages; ma
On Thu Feb 27, 2025 at 7:29 AM GMT, Jan Beulich wrote:
> On 26.02.2025 18:33, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2025 at 02:11:23PM +0100, Jan Beulich wrote:
> >> On 18.02.2025 15:22, Alejandro Vallejo wrote:
> >>> Today, Xen hardcodes apic_id = vcpu_id * 2, but this is unwise and
> >>> int
On Wed Feb 26, 2025 at 1:11 PM GMT, Jan Beulich wrote:
> On 18.02.2025 15:22, Alejandro Vallejo wrote:
> > Today, Xen hardcodes apic_id = vcpu_id * 2, but this is unwise and
> > interferes with providing accurate topology information to the guest.
> >
> > Introduce a new x2apic_id field into hvm_h
Hi,
On Wed Feb 26, 2025 at 5:33 PM GMT, Roger Pau Monné wrote:
> On Wed, Feb 26, 2025 at 02:11:23PM +0100, Jan Beulich wrote:
> > On 18.02.2025 15:22, Alejandro Vallejo wrote:
> > > Today, Xen hardcodes apic_id = vcpu_id * 2, but this is unwise and
> > > interferes with providing accurate topology
On Wed, Feb 26, 2025 at 06:18:46PM -0800, Sean Christopherson wrote:
> Silently ignore attempts to switch to a paravirt sched_clock when running
> as a CoCo guest with trusted TSC. In hand-wavy theory, a misbehaving
> hypervisor could attack the guest by manipulating the PV clock to affect
> guest
On Wed, Feb 26, 2025 at 06:18:22PM -0800, Sean Christopherson wrote:
> 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 alway
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2025-1713 / XSA-467
deadlock potential with VT-d and legacy PCI device pass-through
ISSUE DESCRIPTION
=
When setting up interrupt remapping for legacy PCI(-X) devices,
including PCI(-X) bri
On 26/02/2025 9:11 pm, Jason Andryuk wrote:
> @@ -316,6 +327,19 @@ static void apply_quirks(struct pci_dev *pdev)
> * from trying to size the BARs or add handlers to trap accesses.
> */
> pdev->ignore_bars = true;
> +
> +for ( i = 0; i < ARRAY_SIZE(hide_
On Wed, Feb 26, 2025 at 04:11:25PM -0500, Jason Andryuk wrote:
> Sometimes we have to quirk the PCI IRTE to use a non-zero remap_index
> corresponding to the guest's view of the MSI data register. The MSI
> data guest vector equals interrupt remapping table index.
I think you need some introducti
On 26.02.2025 22:11, Jason Andryuk wrote:
> Sometimes we have to quirk the PCI IRTE to use a non-zero remap_index
> corresponding to the guest's view of the MSI data register. The MSI
> data guest vector equals interrupt remapping table index.
>
> The ath11k wifi device does unusual things with M
On 26.02.2025 21:10, Jason Andryuk wrote:
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -901,7 +901,10 @@ int libxl__arch_hvm_map_gsi(libxl__gc *gc, uint32_t
> sbdf, uint32_t domid)
> int pirq = -1, gsi, r;
>
> gsi = xc_pcidev_get_gsi(CTX->xch, sbdf);
>
On 26.02.2025 21:01, Jason Andryuk wrote:
> A PCI may not have a legacy IRQ. In that case, do not fail assigning
Nit: Missing "device".
> to the pciback stub. Instead just skip xen_pvh_setup_gsi().
>
> This will leave psdev->gsi == -1. In that case, when reading the value
> via IOCTL_PRIVCMD_
On 26.02.2025 18:20, Andrew Cooper wrote:
> --- a/xen/arch/riscv/include/asm/bitops.h
> +++ b/xen/arch/riscv/include/asm/bitops.h
> @@ -125,6 +125,13 @@ static inline void clear_bit(int nr, volatile void *p)
> #undef NOT
> #undef __AMO
>
> +#define arch_ffs(x) ((x) ? 1 + __builtin_ctz(x) :
42 matches
Mail list logo
