This removes the unnecessary work of splitting a 32-bit number across
4 registers, and recombining later. Bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-295 (-295)
Function old new delta
enable_iommu
On 30/01/2025 11:11 am, Jan Beulich wrote:
> While the 2nd of the commits referenced below should have moved the call
> to amd_iommu_msi_enable() instead of adding another one, the situation
> wasn't quite right even before: It can't have done any good to enable
> MSI when no IRQ was allocated for
On 30/01/2025 11:13 am, Jan Beulich wrote:
> Despite all the verbosity with "iommu=debug", information on the IOMMUs
> themselves was missing.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
This is a sanity check that an algorithm in Xen matches hardware. It is
only compiled into debug builds by default.
Given that you're running under virtualbox, i have a suspicion as to what's
wrong.
Can you collect the full `xen-cpuid -p` output from within your
environment? I don't believe you
Yes sure I can collect the output. As you said the change is good enough to
start the dom0 without errors (at least no apparent errors :).
```
Xen reports there are maximum 120 leaves and 2 MSRs
Raw policy: 32 leaves, 2 MSRs
CPUID:
leaf subleaf -> eax ebx ecx edx
:f
On 02/02/2025 4:58 pm, Guillaume wrote:
> I attached the output of the `xl dmesg`. This is the 4.19.1 kernel I
> rebuild but I have the same issue with master (just for info).
Thanks. This is a TigerLake CPU, and:
> (XEN) Mitigating GDS by disabling AVX while virtualised - protections
> are best
Can you also get `xl dmesg` too, and attach it?
I think this is a VirtualBox bug, but I'm confused as to why Xen has
decided to turn off AVX.
~Andrew
On 02/02/2025 4:01 pm, Guillaume wrote:
> Yes sure I can collect the output. As you said the change is good
> enough to start the dom0 without err
On Sun, Feb 02, 2025 at 12:08:46AM -0500, Demi Marie Obenour wrote:
> Recently, AMD submitted patches to the dri-devel mailing list to support
> using application-provided buffers in virtio-GPU. This feature is
> called Shared Virtual Memory (SVM) and it is implemented via an API
> called User Poi
Sean Christopherson writes:
> Extract retrieval of TSC frequency information from CPUID into standalone
> helpers so that TDX guest support and kvmlock can reuse the logic. Provide
s/kvmlock/kvmclock
> a version that includes the multiplier math as TDX in particular does NOT
> want to use nativ
On 01.02.2025 00:36, Tamas K Lengyel wrote:
> On Fri, Jan 31, 2025 at 1:30 AM Jan Beulich wrote:
>> On 31.01.2025 01:26, Tamas K Lengyel wrote:
>>> On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
On 21.01.2025 11:19, Sergiy Kibrik wrote:
> Use more generic CONFIG_VM_EVENT name through
Hello,
I'd like to report an issue I encountered when building Xen from source.
To give you some context, During the Xen winter meetup in Grenoble few days
ago, there was a discussion about strengthening collaboration between Xen
and academia. One issue raised by a professor was that Xen is harde
On 30/01/2025 11:12 am, Jan Beulich wrote:
> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
> have permanent effect, pci_segments_init() needs to be called ahead of
> making it there. Without this we're losing segment 0's r/o map, and thus
> we're losing write-protection of t
I attached the output of the `xl dmesg`. This is the 4.19.1 kernel I
rebuild but I have the same issue with master (just for info).
And also as you said earlier it works with the default installation because
I see that the first line is:
`(XEN) [001476779e16] Xen version 4.19.1 (Debian 4.19.1-
13 matches
Mail list logo
