On Thu, 13 Mar 2025 at 19:59, Jason Andryuk wrote:
>
> On 2025-03-13 14:57, Andrii Sultanov wrote:
> > Following on from 250d87dc, struct amd_iommu has its seg and bdf fields
> > backwards with relation to pci_sbdf_t. Swap them around, and simplify the
> > expressions regenerating an sbdf_t from s
On Thu, 13 Mar 2025 at 20:16, Andrew Cooper wrote:
>
> On 13/03/2025 6:57 pm, Andrii Sultanov wrote:
> > Following on from 250d87dc, struct amd_iommu has its seg and bdf fields
> > backwards with relation to pci_sbdf_t. Swap them around, and simplify the
> > expressions regenerating an sbdf_t from
On Thu, 13 Mar 2025 at 18:57, Andrii Sultanov wrote:
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -297,7 +297,7 @@ static int __init register_range_for_iommu_devices(
> /* reserve unity-mapped page entries for devices */
> for ( b
On 4/15/25 8:05 AM, dm...@proton.me wrote:
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -707,8 +707,7 @@ static int __init cf_check parse_ivrs_ioapic(const char
*str)
}
}
-ioapic_sbdf[idx].bdf = PCI_BDF(bus, dev, func);
-
On 4/15/25 8:34 AM, dm...@proton.me wrote:
On Mon, Apr 14, 2025 at 08:19:16PM +0100, Andrii Sultanov wrote:
From: Andrii Sultanov
Following on from 250d87dc3ff9 ("x86/msi: Change __msi_set_enable() to
take pci_sbdf_t"), make struct amd_iommu contain pci_sbdf_t directly
instead of specifying
On 6/24/25 3:51 PM, Andriy Sultanov wrote:
Suggestion:
WATCH_EVENT's req_id and tx_id are currently 0. Could it be possible, for
example, to modify this such that watch events coming as a result of a
transaction commit (a "batch") have tx_id of the corresponding
transaction
and
Currently, as far as I am aware, the ability of xenstore clients to properly
handle and detect batch updates is somewhat lacking. Transactions are not
directly visible to the clients watching a particular directory - they will
receive a lot of individual watch_event's once the transaction is commi
On 6/24/25 4:06 PM, Jürgen Groß wrote:
The main reason for the large number of watch events after a
transaction is
the fact that the watch for e.g. detecting the addition of a new block
device
will be set on a node being common for all potential block devices
handled
by the watcher. This resul
> diff --git a/tools/xentop/xentop.c b/tools/xentop/xentop.c
> index f5d6c19cf9..477299c883 100644
> --- a/tools/xentop/xentop.c
> +++ b/tools/xentop/xentop.c
> @@ -69,6 +70,12 @@
>
> #define INT_FIELD_WIDTH(n) ((unsigned int)(log10(n) + 1))
>
> +/* TEMPORARY: Forward declare the internal structu
On 7/21/25 7:25 AM, Jan Beulich wrote:
On 19.07.2025 00:03,dm...@proton.me wrote:
On Thu, Jul 17, 2025 at 08:31:27AM +0100, Andrii Sultanov wrote:
@@ -335,20 +336,19 @@ void cf_check amd_iommu_ioapic_update_ire(
new_rte.raw = rte;
/* get device id of ioapic devices */
-bdf = i
--+ |
> + * |##pad#######| |
> + * +===+=+===+==+===+ |
> + * | guest | | r | regs |##pad##| |
> + * +---. +---. (xen or guest) |###| |
> + * | +==+===+ |
> + * | |##pad2| |
> PAGE_SIZE
> + * +=+==+ <.
> */
>
> #endif /* __XEN_PUBLIC_ARCH_X86_PMU_H__ */
Andriy Sultanov | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
11 matches
Mail list logo
