On Sun, Feb 02, 2025 at 12:08:46AM -0500, Demi Marie Obenour wrote:
> Cc:
> Bcc:
> Subject: Xen requirements for GPU virtualization via virtio-GPU
> Reply-To:
> X-Mutt-Fcc: =INBOX,=xen-devel,=Sent
> X-Mutt-PGP: S
>
> Recently, AMD submitted patches to the dri-devel mailing list to support
> usi
On Thu, Feb 06, 2025 at 05:39:00PM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
^ AMD?
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
>
> Ac
On Tue, Feb 04, 2025 at 02:04:35PM +0100, 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 actually does.
>
> Signed-off-by: Jan Beulich
IMO I would rather no
On Thu, Feb 06, 2025 at 02:55:44PM +, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 3:18 PM GMT, Alejandro Vallejo wrote:
> > Hi,
> >
> > I picked v4 of this series and run it through XenRT extensively, fixing
> > crashes
> > and errors as I hit them. Likewise, I've run it through Gitlab, f
to Xen, that doesn't mean
> > Linux cannot use them. By inhibiting the usage of
> > VMD_FEAT_CAN_BYPASS_MSI_REMAP and the removal of the pci_msi_ignore_mask
> > bodge devices behind a VMD bridge do work fine when use from a Linux Xen
> > hardware domain. That's the whole point of the series.
> >
> > Signed-off-by: Roger Pau Monné
>
> Needs an ack from Thomas.
Thanks, moved him to the 'To:' field.
Regards, Roger.
Ping? This has been pending for 3 weeks without replies.
Thanks, Roger.
On Tue, Jan 14, 2025 at 11:33:10AM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series should fix the usage of devices behind a VMD bridge
> when running Linux as a Xen PV hardware domain (dom0). I've only been
On Wed, Feb 05, 2025 at 03:42:30AM +, Chen, Jiqian wrote:
> 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
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;
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
&
On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead. On x86 move the
> invocation back to acpi_mmcfg_init(), where it was prior to
> ("x86/PCI: init segments earlier").
> ---
> v2: New.
>
> --- a/xen/arch/arm/pci/pci.c
; done it already (by way of invoking iommu_msi_unmask()).
>
> Fixes: 5f569f1ac50e ("AMD/IOMMU: allow enabling with IRQ not yet set up")
> Fixes: d9e49d1afe2e ("AMD/IOMMU: adjust setup of internal interrupt for
> x2APIC mode")
> Signed-off-by: Jan Beulich
> Reviewe
On Thu, Jan 30, 2025 at 12:12:31PM +0100, 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 wri
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 Vallejo wrote:
> > > The hypervisor, hvmloader and the toolstack currently engage in a share
On Tue, Jan 28, 2025 at 04:33:40PM +, Alejandro Vallejo wrote:
> 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
On Tue, Jan 28, 2025 at 04:33:39PM +, Alejandro Vallejo wrote:
> The hypervisor, hvmloader and the toolstack currently engage in a shared
> assumption that for every vCPU apicid == 2 * vcpuid. This series removes such
> assumption from hvmloader, by making it read the APIC ID of each vCPU and
>
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:
> >>> * C
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
> > architecture.
> > * In rebar_ctrl_write used "bar - pdev->vpci->header.bars" to get index
> >
On Mon, Jan 27, 2025 at 01:06:51PM +0100, Jan Beulich wrote:
> On 27.01.2025 12:31, Roger Pau Monné wrote:
> > On Mon, Jan 27, 2025 at 11:15:22AM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/include/asm/asm-defns.h
> >> +++ b/xen/arch/x86/include/asm/as
On Mon, Jan 27, 2025 at 11:15:22AM +0100, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000 through
> 0x80007fff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon
On Mon, Jan 27, 2025 at 10:52:47AM +0100, Jan Beulich wrote:
> On 24.01.2025 13:01, Roger Pau Monne wrote:
> > From: Teddy Astie
> >
> > As CX16 support is mandatory for IOMMU usage, the checks for CX16 in the
> > interrupt remapping code are stale. Remove them together with the
> > associated c
On Mon, Jan 27, 2025 at 10:51:29AM +0100, Jan Beulich wrote:
> On 24.01.2025 13:01, Roger Pau Monne wrote:
> > From: Teddy Astie
> >
> > All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> > initialisation time, and remove the effectively-dead logic for the
> > non-cx16 case.
>
On Fri, Jan 24, 2025 at 01:26:23PM -0800, Elliott Mitchell wrote:
> On Fri, Jan 24, 2025 at 03:31:30PM +0100, Roger Pau Monné wrote:
> > On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > > Apparently this was first noticed with 4.14, but more recently I
On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> Apparently this was first noticed with 4.14, but more recently I've been
> able to reproduce the issue:
>
> https://bugs.debian.org/988477
>
> The original observation features MD-RAID1 using a pair of Samsung
> SATA-attached fla
On Fri, Jan 24, 2025 at 02:24:34PM +, Andrew Cooper wrote:
> On 24/01/2025 12:01 pm, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series is the original CX16 series sent by Teddy, with the
> > CX16 checks split into a separate patch, plus one extra patch to switch
> > AMD-Vi to use C
t vmx_vmfunc
For the "convert ..." ones:
Acked-by: Roger Pau Monné
I've taken a quick look and it all looks like mechanical
transformations.
Thanks, Roger.
On Fri, Jan 24, 2025 at 11:51:37AM +0100, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> > It's effectively redundant with vmx_basic_msr. For the #define
> > replacement to work, struct vmcs_struct's respective field name also
>
_after_init right away.
>
> Suggested-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Mon, Feb 26, 2024 at 05:42:50PM +0100, Jan Beulich wrote:
> It's effectively redundant with vmx_basic_msr. For the #define
> replacement to work, struct vmcs_struct's respective field name also
> needs to change: Drop the not really meaningful "vmcs_" prefix from it.
>
> Signed-off-by: Jan Beul
On Mon, Feb 26, 2024 at 05:42:02PM +0100, Jan Beulich wrote:
> While generally benign, doing so is still at best misleading.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, Jan 23, 2025 at 05:14:39PM +0100, Jan Beulich wrote:
> On 23.01.2025 15:24, Roger Pau Monné wrote:
> > On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> >> On 23.01.2025 13:41, Roger Pau Monné wrote:
> >>> On Mon, Feb 26, 2024 at 05:42
On Thu, Jan 23, 2025 at 02:18:41PM +0100, Jan Beulich wrote:
> On 23.01.2025 13:41, Roger Pau Monné wrote:
> > On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -161,10 +
On Thu, Jan 23, 2025 at 01:44:34PM +0100, Jan Beulich wrote:
> On 23.01.2025 12:54, Roger Pau Monné wrote:
> > On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> >> The original implementation has two issues: For one it doesn't preserve
> >> non-canon
further necessary to have the un-adjusted caller buffer
> passed into there.
>
> Fixes: 2d527ba310dc ("x86/hvm: split all linear reads and writes at page
> boundary")
> Reported-by: Manuel Andreas
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Mon, Feb 26, 2024 at 05:42:20PM +0100, Jan Beulich wrote:
> __init{const,data}_cf_clobber can have an effect only for pointers
> actually populated in the respective tables. While not the case for SVM
> right now, VMX installs a number of pointers only under certain
> conditions. Hence the respe
On Thu, Jan 23, 2025 at 10:49:36AM +0100, Jan Beulich wrote:
> On 22.01.2025 18:45, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
> >> The MMIO cache is intended to have one entry used per independent memory
> >> access
On Tue, Nov 05, 2024 at 02:56:42PM +0100, Jan Beulich wrote:
> The original implementation has two issues: For one it doesn't preserve
> non-canonical-ness of inputs in the range 0x8000 through
> 0x80007fff. Bogus guest pointers in that range would not cause a
> (#GP) fault upon
IW, I find this easier to read as `size + offset > PAGE_SIZE` (which
is the same condition used in linear_{read,write}().
Preferably with that adjusted:
Acked-by: Roger Pau Monné
Thanks, Roger.
On Wed, Jan 22, 2025 at 02:39:43PM +0100, Jan Beulich wrote:
> On 22.01.2025 13:00, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2024 at 10:49:10AM +0200, Jan Beulich wrote:
> >> Both caches may need higher capacity, and the upper bound will need to
> >> be determined
On Tue, Oct 01, 2024 at 10:49:40AM +0200, Jan Beulich wrote:
> The MMIO cache is intended to have one entry used per independent memory
> access that an insn does. This, in particular, is supposed to be
> ignoring any page boundary crossing. Therefore when looking up a cache
> entry, the access'es
On Tue, Oct 01, 2024 at 10:49:10AM +0200, Jan Beulich wrote:
> Both caches may need higher capacity, and the upper bound will need to
> be determined dynamically based on CPUID policy (for AMX'es TILELOAD /
> TILESTORE at least).
>
> Signed-off-by: Jan Beulich
Just a couple of comments below.
>
On Tue, Oct 01, 2024 at 10:48:20AM +0200, Jan Beulich wrote:
> To avoid overrunning the internal buffer we need to take the offset into
> the buffer into account.
>
> Fixes: d95da91fb497 ("x86/HVM: grow MMIO cache data size to 64 bytes")
> Signed-off-by: Jan Beulich
Rev
s not zero-extended.)
>
> Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn
> handling with zero count")
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
> ---
> Partly RFC for none of this being documented anywhere (and it partly
> be
On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
> On 21.01.2025 19:02, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 09:52, Roger Pau Monné wrote:
> >>> On Tue, Jan 21, 2025 at 09:13:38AM +0100
On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> On 21.01.2025 09:52, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>> On Mon, 20 Jan 2025, Jan Beulich wro
s too.
>
> Reported-by: Jonathan Katz
> Link: https://xcp-ng.org/forum/topic/10286/nesting-xcp-ng-on-esx-8
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Oleksii Kurochko
>
> Untested, but this is the same pattern used by opro
On Tue, Jan 21, 2025 at 12:20:17PM +0100, Jan Beulich wrote:
> On 21.01.2025 12:09, Roger Pau Monné wrote:
> > On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> >> On 18.04.2024 13:57, Teddy Astie wrote:
> >>> All hardware with VT-d/AMD-Vi has CMP
On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> On 18.04.2024 13:57, Teddy Astie wrote:
> > All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> > initialisation time, and remove the effectively-dead logic for the
> > non-cx16 case.
>
> As before: What about Xen its
On Tue, Jan 21, 2025 at 09:10:26AM +, Chen, Jiqian wrote:
> On 2025/1/21 16:46, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> >> +ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> >&g
>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano
On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
>
> According to PCIe spec, each bar that supports
On Tue, Jan 14, 2025 at 04:02:01PM +0100, Jan Beulich wrote:
> On 09.01.2025 18:33, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
> >> On 08.01.2025 15:26, Roger Pau Monne wrote:
> >>> }
> >>> else
&g
On Tue, Jan 14, 2025 at 05:20:04PM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > Hello,
> >
> > The aim of this series is to introduce the functionality required to
> > create linear mappings visible to a single pCPU.
> >
> > Doing so requires having a per-vCPU root
On Tue, Jul 09, 2024 at 09:08:11AM -0400, Jason Andryuk wrote:
> On 2024-07-09 06:56, Jürgen Groß wrote:
> > On 09.07.24 09:01, Jan Beulich wrote:
> > > On 09.07.2024 08:36, Jürgen Groß wrote:
> > > > On 09.07.24 08:24, Jan Beulich wrote:
> > > > > On 08.07.2024 23:30, Jason Andryuk wrote:
> > > >
On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> On Wed, 1 Mar 2023, Jan Beulich wrote:
> > While we want certain things turned off in shim-exclusive mode, doing
> > so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> > that will turn on PV_SHIM_EXCLUSIVE
e install of the plain python package for
> > full
> > builds.
> >
> > Signed-off-by: Roger Pau Monné
>
> That looks cleaner, and likely to have better longevity. Thanks.
>
> Reviewed-by: Andrew Cooper
Forgot to Cc Oleksii on the patches, as I would like a Release-Ack.
Thanks, Roger.
dconfig builds. Such randconfig builds are relevant because FreeBSD
> > is the only tested system that has a full non-GNU toolchain.
> >
> > While there remove the stale `python` package install in the full build
> > case: this is no longer needed if `python311` is also spec
()
> hw/xen: Use xs_node_read() from xenstore_read_str() instead of
> open-coding it
Acked-by: Roger Pau Monné
> I'm slightly dubious about the last one; xen_pvdev.c didn't previously
> use anything from xen-bus-helper.c and even hardcodes zero for
> XBT_NULL. And
On Wed, Jan 15, 2025 at 09:19:29AM +0100, Jan Beulich wrote:
> On 14.01.2025 18:43, Roger Pau Monne wrote:
> > If randconfig enables coverage support the build times out due to GNU LD
> > taking too long. For the time being prevent coverage from being enabled in
> > clang randconfig job.
>
> Just
clang randconfig job.
> >
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Andrew Cooper
Thanks.
> > ---
> > Cc: Oleksii Kurochko
> > ---
> > I will fix the orphaned section stuff separately, as I'm considering just
> > removing LLVM coverage s
On Tue, Jan 14, 2025 at 03:48:54PM +0100, Nicola Vetrini wrote:
> Simone Ballarin is no longer actively involved in reviewing
> the ECLAIR integration for Xen. I am stepping up as a reviewer.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Roger Pau Monné
Adding Simone to the Cc list,
On Tue, Jan 14, 2025 at 03:23:21PM +0100, Oleksii Kurochko wrote:
>
> On 1/14/25 1:13 PM, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
> > > On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> > > >
> > > &g
On Tue, Jan 14, 2025 at 12:44:39PM +0100, Oleksii Kurochko wrote:
>
> On 1/14/25 12:40 PM, Oleksii Kurochko wrote:
> >
> >
> > On 1/14/25 12:27 PM, Roger Pau Monné wrote:
> > > On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
> > > &
On Tue, Jan 14, 2025 at 12:24:30PM +0100, Nicola Vetrini wrote:
> On 2025-01-14 12:22, Roger Pau Monné wrote:
> > Hello Oleksii,
> >
> > This is in principle ready to go in now (I'm currently running a
> > private Eclair scan to ensure the patch is still OK agains
On Tue, Jan 14, 2025 at 12:12:03PM +0100, Oleksii Kurochko wrote:
>
> On 1/13/25 6:52 PM, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 05:07:55PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Fri, Sep 13, 2024 at 09:59:06AM +0200, Roger Pau Monne wrote:
> >
e are no violations left, make the rule globally blocking for both x86 and
> ARM.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Andrew Cooper
> ---
> automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff
On Mon, Jan 13, 2025 at 09:53:21AM -0700, Keith Busch wrote:
> On Mon, Jan 13, 2025 at 05:45:20PM +0100, Roger Pau Monné wrote:
> > On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> > > On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monné wrote:
> > > &
On Tue, Jan 14, 2025 at 10:32:25AM +0100, Roger Pau Monné wrote:
> On Mon, Jan 13, 2025 at 06:42:44PM +, Teddy Astie wrote:
> > Solaris 11.4 tries to access this MSR on some Intel platforms without
> > properly
> > setting up a proper #GP handler, which leads
On Mon, Jan 13, 2025 at 06:42:44PM +, Teddy Astie wrote:
> Solaris 11.4 tries to access this MSR on some Intel platforms without properly
> setting up a proper #GP handler, which leads to a immediate crash.
>
> Emulate the access of this MSR by giving it a legal value (all values set to
> defa
obing is bypassed and the selected
> > implementation is used (as long as it's available).
> >
> > The `xen` and `efi` options require being booted as a Xen guest (with Xen
> > guest
> > supported built-in) or from UEFI firmware respectively.
> >
> >
On Mon, Jan 13, 2025 at 08:11:19AM -0700, Keith Busch wrote:
> On Mon, Jan 13, 2025 at 11:03:58AM +0100, Roger Pau Monné wrote:
> >
> > Hm, OK, but isn't the limit 80 columns according to the kernel coding
> > style (Documentation/process/coding-style.rst)?
>
&
On Fri, Jan 10, 2025 at 04:30:57PM -0600, Bjorn Helgaas wrote:
> Match subject line style again.
>
> On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> > Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
> > MSI
> > and MSI-X entries globally, regardless o
On Fri, Jan 10, 2025 at 04:21:29PM -0600, Bjorn Helgaas wrote:
> On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> > The PCI segment value is limited to 16 bits, however there are buses like
> > VMD
> > that fake being part of the PCI topology by adding segment with a number
> > o
On Mon, Jan 13, 2025 at 08:17:23AM +0100, Jan Beulich wrote:
> On 10.01.2025 15:01, Roger Pau Monne wrote:
> > The PCI segment value is limited to 16 bits, however there are buses like
> > VMD
> > that fake being part of the PCI topology by adding segment with a number
> > outside the scope of the
On Fri, Jan 10, 2025 at 10:02:00PM -0700, Jonathan Derrick wrote:
> Hi Bjorn,
>
> On 1/10/25 3:25 PM, Bjorn Helgaas wrote:
> > Match historical subject line style for prefix and capitalization:
> >
> >PCI: vmd: Set devices to D0 before enabling PM L1 Substates
> >PCI: vmd: Add DID 8086:B0
applies. That would
require changes in both Xen and Linux to propagate the VMD information
into Xen.
> > Signed-off-by: Roger Pau Monné
> > ---
> > drivers/pci/controller/vmd.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers
On Fri, Jan 10, 2025 at 04:19:03PM +, Alejandro Vallejo wrote:
> On Fri Jan 10, 2025 at 3:02 PM GMT, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2025 at 03:08:15PM +, Alejandro Vallejo wrote:
> > > On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > >
introduces some duplication in the domain and vcpu structures, as both
> > contain a mapcache field to support running with and without per-vCPU
> > page-tables.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch/x86/domain_page.c| 90 +
led, even if the feature is non-functional.
> >
> > When ASI is enabled for PV domains, printing the usage of XPTI might be
> > omitted if it must be uniformly disabled given the usage of ASI.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Changes since
t; area, as that allows dropping the extra taken page reference when removing
> > the
> > mappings.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch/x86/include/asm/domain.h | 2 ++
> > xen/arch/x86/pv/descriptor-tables.c | 19 ++-
&g
On Thu, Jan 09, 2025 at 11:01:00AM +, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 2:26 PM GMT, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
> > index 65cd751087dc..0c57442c9593 100644
> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b
On Thu, Jan 09, 2025 at 10:25:50AM +, Alejandro Vallejo wrote:
> On Wed Jan 8, 2025 at 3:11 PM GMT, Roger Pau Monne wrote:
> > The pv_{set,destroy}_gdt() functions rely on the L1 table(s) that contain
> > such
> > mappings being stashed in the domain structure, and thus such mappings being
> >
be a vCPU instead of
> > a
> > domain, and also update the function logic to allow manipulation of
> > per-domain
> > mappings using the linear page table mappings.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch
the L1 table of the per-domain region.
> >
> > Using such function to populate per-domain addresses drops the need to keep
> > a
> > reference to per-domain L1 tables previously used to change the per-domain
> > mappings.
> >
> > Signed-off-by: Roger Pau Monn
On Thu, Jan 09, 2025 at 10:10:20AM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > The current code to update the Xen part of the GDT when running a PV guest
> > relies on caching the direct map address of all the L1 tables used to map
> > the
> > GDT and LDT, so that e
On Thu, Jan 09, 2025 at 03:57:24PM -0800, Stefano Stabellini wrote:
> On Thu, 9 Jan 2025, Nicola Vetrini wrote:
> > On 2025-01-04 01:20, Stefano Stabellini wrote:
> > > Hi Nicola, one question below
> > >
> > > On Wed, 27 Nov 2024, Nicola Vetrini wrote:
> > > > > #define AMD_OSVW_ERRATUM(osvw_id,
vcpu should signal
what page-tables are loaded).
The main point apart from more accurate signaling of the loaded
page-tables is to avoid infinite recursion if sync_local_execstate()
is called inside the context switch path.
> That's essential for implementing FPU hiding as propos
On Thu, Jan 09, 2025 at 09:59:58AM +0100, Jan Beulich wrote:
> On 08.01.2025 15:26, Roger Pau Monne wrote:
> > On x86 Xen will perform lazy context switches to the idle vCPU, where the
> > previously running vCPU context is not overwritten, and only current is
> > updated
> > to point to the idle
On Thu, Jan 09, 2025 at 11:25:13AM +, David Woodhouse wrote:
> On Thu, 2025-01-09 at 11:59 +0100, Anthony PERARD wrote:
> >
> > > char label[32];
> > > XenDevice *xendev = NULL;
> > > XenConsole *con;
> > > @@ -550,7 +551,10 @@ static void
> > > xen_console_device_create(Xen
> >
> > Fixes: a783f8ad4ec9 ('xen: add a mechanism to automatically create
> > XenDevice-s...')
> > Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
> > Signed-off-by: Roger Pau Monné
> > ---
> > hw/char/xen_console.c | 1
0x43944c929000, errp=0x15cd0165ae10)
> > at ../qemu-xen-dir-remote/hw/char/xen_console.c:555
> >
> > Replace usages of error_prepend() with error_setg() where appropriate.
> >
> > Fixes: 9b7737469080 ('hw/xen: update Xen console to XenDevice model')
>
On Wed, Jan 08, 2025 at 04:29:24PM -0800, Stefano Stabellini wrote:
> On Wed, 8 Jan 2025, Denis Mukhin wrote:
> > On Wednesday, January 8th, 2025 at 12:35 AM, Roger Pau Monné
> > wrote:
> > > On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> > >
On Wed, Jan 08, 2025 at 09:13:02AM +0100, Jan Beulich wrote:
> On 08.01.2025 09:04, Roger Pau Monné wrote:
> > On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> >> On 08.01.2025 00:40, Stefano Stabellini wrote:
> >>> On Tue, 7 Jan 2025, Jan Beulich wro
On Tue, Jan 07, 2025 at 09:32:05AM +0100, Jan Beulich wrote:
> On 06.01.2025 23:01, Stefano Stabellini wrote:
> > On Mon, 6 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 12:08, Andrew Cooper wrote:
> >>> On 06/01/2025 11:04 am, Jan Beulich wrote:
> These interfaces were - afaict - originally
On Wed, Jan 08, 2025 at 08:28:32AM +0100, Jan Beulich wrote:
> On 08.01.2025 00:40, Stefano Stabellini wrote:
> > On Tue, 7 Jan 2025, Jan Beulich wrote:
> >> On 06.01.2025 19:48, Stefano Stabellini wrote:
> >>> On Mon, 6 Jan 2025, Jan Beulich wrote:
> On 04.01.2025 05:15, Denis Mukhin wrote:
>
On Wed, Jan 08, 2025 at 08:19:55AM +0100, Jan Beulich wrote:
> On 07.01.2025 19:19, Roger Pau Monné wrote:
> > On Tue, Jan 07, 2025 at 04:58:07PM +0100, Jan Beulich wrote:
> >> On 07.01.2025 15:38, Roger Pau Monné wrote:
> >>> On Tue, Jan 07, 2025 at 11:06:33AM +0100
On Tue, Jan 07, 2025 at 04:58:07PM +0100, Jan Beulich wrote:
> On 07.01.2025 15:38, Roger Pau Monné wrote:
> > On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
> >> On 19.12.2024 06:21, Jiqian Chen wrote:
> >>> --- /dev/null
> >>> +++ b/xen
On Sat, Jan 04, 2025 at 05:19:07AM +, Denis Mukhin wrote:
> On Friday, December 13th, 2024 at 4:23 AM, Roger Pau Monné
> wrote:
> > Albeit PVH is kind of HVM.
>
> PVH does not have vPIC so there's some more work to enable vUART
> for PVH on x86: emulator curren
On Tue, Jan 07, 2025 at 11:06:33AM +0100, Jan Beulich wrote:
> On 19.12.2024 06:21, Jiqian Chen wrote:
> > --- /dev/null
> > +++ b/xen/drivers/vpci/rebar.c
> > @@ -0,0 +1,131 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Righ
4 user->kernel boundary to have the
>property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
>guests when the BP_SPEC_REDUCE precondition is met.
>
> Finally, fix a typo in the SRSO_NO's comment.
>
> [1]
> https://www.amd.com/content/dam/amd/e
creasing the block size to 256MiB. And remove the
> misleading comment (from lack of better ideas).
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Roger Pau Monné
I assumed I already RB this, but it seems not.
Could we get an Ack from the tools or libs maintainer for this to go
in? It's not the best solution, but we need to get this sorted in
time for 4.20, and backport to stable branches.
Thanks, Roger.
1 - 100 of 3458 matches
Mail list logo
