Alejandro, Sairaj,
On 7/17/2025 7:18 PM, Alejandro Jimenez wrote:
>
>
> On 7/17/25 2:07 AM, Michael S. Tsirkin wrote:
>> On Thu, Jul 17, 2025 at 11:17:05AM +0530, Sairaj Kodilkar wrote:
>>>
>>>
>>> On 7/16/2025 6:59 PM, Michael S. Tsirkin wrote:
On Wed, Jul 16, 2025 at 06:26:37PM +0530, Sa
Hi Michael,
On 6/17/2025 8:34 PM, Alejandro Jimenez wrote:
> Added two new changes based on observations from Ethan. Like the rest of
> the fixes in this series, these do not trigger problems today given the
> limited feature set supported. Re-tested the series with emulated devices,
> VFIO passt
lso modified, since it was incorrectly encoded.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Co-developed-by: Ethan MILON
> Signed-off-by: Ethan MILON
> Signed-off-by: Alejandro Jimenez
Reviewed-by: Vasant Hegde
-Vasant
`oldval` to match the return type of `ldq_le_p()`.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Ethan Milon
Reviewed-by: Vasant Hegde
-Vasant
Alejandro,
On 5/2/2025 7:45 AM, Alejandro Jimenez wrote:
> Make amdvi_get_pte_entry() return an error value (-1) in cases where the
> memory read fails, versus the current return of 0 to indicate failure.
> The reason is that 0 is also a valid PTE value, and it is useful to know
If PTE is valid
Alejandro,
On 5/2/2025 7:45 AM, Alejandro Jimenez wrote:
> Invalidating the entire address space (i.e. range of [0, ~0ULL]) is a
> valid and required operation by vIOMMU implementations. However, such
> invalidations currently trigger an assertion unless they originate from
> device IOTLB invalid
Hi,
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> Correct mistakes in bitmasks, offsets, decoding of fields, and behavior that
> do not match the latest AMD I/O Virtualization Technology (IOMMU)
> Specification. These bugs do not trigger problems today in the limited mode
> of operation support
; Convert masks to use GENMASK64 for consistency, and make unrelated
> definitions independent.
>
> Cc: qemu-sta...@nongnu.org
> Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Alejandro Jimenez
This patch makes it easy to read macros! Thanks.
Revie
e AMD I/O
> Virtualization Technology (IOMMU) Specification for the Interrupt Table
> Root Pointer[51:6] field in the Device Table Entry format.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Alejandro Jimenez
I found this issue last week when I was going through the code!Thanks for
fixing.
R
On 5/29/2025 3:47 AM, Alejandro Jimenez wrote:
> No functional change.
>
> Signed-off-by: Alejandro Jimenez
I had similar fix locally :-) Thanks for fixing it.
Reviewed-by: Vasant Hegde
-Vasant
Hi Philippe,
On 5/16/2025 8:08 PM, Philippe Mathieu-Daudé wrote:
> Hi,
>
> On 16/5/25 12:05, Sairaj Kodilkar wrote:
>> From: Vasant Hegde
>>
>> If vCPUs > 255 then x86 common code (x86_cpus_init()) call
>> kvm_enable_x2apic().
>> But if vCP
ough mode")
> Signed-off-by: Sairaj Kodilkar
Reviewed-by: Vasant Hegde
-Vasant
gt; Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Alejandro Jimenez
I did double check and I think this patch matches HW behaviour. I did run few
tests w/ this series. It seems to work fine for me.
Reviewed-by: Vasa
Hi Alejandro,
On 3/11/2025 8:54 PM, Alejandro Jimenez wrote:
> The size mask currently encompasses reserved bits [11:9]. Extract only the
> corrects bits encoding size (i.e. [8:0]).
>
> Cc: qemu-sta...@nongnu.org
> Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Alejandro J
gnu.org
> Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Alejandro Jimenez
Fix looks good.
Reviewed-by: Vasant Hegde
FYI. I think we need to reconsider IOTLB invalidation stuff. Its suppose to
invalidate the device side TLB, not IOMMU one. Before that we need to
")
I understand its a fix. But its not breaking anything. So not sure whether its
worth to backport.
> Signed-off-by: Alejandro Jimenez
Reviewed-by: Vasant Hegde
-Vasant
> ---
> hw/i386/amd_iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
E_QUAD1_RESERVED0
> +#define AMDVI_DTE_QUAD2_RESERVEDGENMASK64(53, 52)
> +#define AMDVI_DTE_QUAD3_RESERVED(GENMASK64(14, 0) | GENMASK64(53,
> 48))
In vIOMMU case guest is not expected to set any value in DTE[3]. So I am
wondering whether to match the spec -OR- what is expected in vIOMMU context. If
we want to go with later then it complicates as there are many other fields like
GV, etc is not expected to be used.
So since this matches the spec I think we are good for now.
Reviewed-by: Vasant Hegde
-Vasant
ixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
> Signed-off-by: Alejandro Jimenez
Good catch. I had read this code but missed to catch this!
Reviewed-by: Vasant Hegde
-Vasant
> ---
> hw/i386/amd_iommu.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Hi ,
On 3/13/2025 7:53 PM, Alejandro Jimenez wrote:
>
>
> On 3/12/25 12:12 AM, Arun Kodilkar, Sairaj wrote:
>> Hi Alejandro,
>>
>> On 3/11/2025 8:54 PM, Alejandro Jimenez wrote:
>
> [...]
>
>>> --- a/hw/i386/amd_iommu.h
>>> +++ b/hw/i386/amd_iommu.h
>>> @@ -25,6 +25,8 @@
>>> #include "hw/i3
Hi,
On 2/26/2025 8:52 PM, Michael Tokarev wrote:
> 26.02.2025 15:53, Vasant Hegde wrote:
>> Hi Michael,
>
> Hi!
>
>> On 2/25/2025 2:17 PM, Michael Tokarev wrote:
> ...>> Is this qemu-stable material (current series: 7.2, 8.2, 9.2)?
>>
>> Linux kerne
Hi Michael,
On 2/25/2025 2:17 PM, Michael Tokarev wrote:
> 07.02.2025 07:53, Sairaj Kodilkar wrote:
>> This series provides few bug fixes for emulated AMD IOMMU. The series is
>> based
>> on top of qemu upstream master commit d922088eb4ba.
>>
>> Patch 1: The code was using wrong DTE field to det
Hi Joao,
On 11/28/2024 10:44 PM, Joao Martins wrote:
> On 21/11/2024 11:42, Joao Martins wrote:> On 20/11/2024 07:31, Suravee
> Suthikulpanit wrote:
>>> Add migration support for AMD IOMMU model by saving necessary AMDVIState
>>> parameters for MMIO registers, device table, command buffer, and ev
age.
>
> Fix a type in "configuration" in error message.
>
> Signed-off-by: Philippe Mathieu-Daudé
Thanks for the fix. Looks good to me.
Reviewed-by: Vasant Hegde
-Vasant
23 matches
Mail list logo
