The kernel uapi/linux/iommu.h header file includes the
extensions for vSVA support. e.g. bind gpasid, iommu
fault report related user structures and etc.
This commit updates kernel headers from the below branch:
https://github.com/luxis1999/linux-vsva.git: vsva-linux-5.8-rc3-v5
Note: this should
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA can reduce programming complexity and enhance security.
This QEMU series is intended to expose SVA usage to VMs. i.e. Sharing
guest
From: Eric Auger
Update the script to import the new iommu.h uapi header.
Cc: Kevin Tian
Cc: Jacob Pan
Cc: Peter Xu
Cc: Yi Sun
Cc: Michael S. Tsirkin
Cc: Cornelia Huck
Cc: Paolo Bonzini
Acked-by: Cornelia Huck
Signed-off-by: Eric Auger
---
scripts/update-linux-headers.sh | 2 +-
1
Great work Simon! I'm not an ACPI expert but that certainly seems a
plausible solution - I'll have to defer the final review to someone else
though.
The quickest way to get this reviewed is to follow the procedure at
https://wiki.qemu.org/Contribute/SubmitAPatch which is basically send a
"git
on a hunch, i applied this, and now macos boots (as 2 from acpi-tmr fits
in the 1-4 range):
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index f6d9ec4f13..05ff29b9d7 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -527,7 +527,7 @@ static void acpi_pm_tmr_write(void *opaque, hwaddr addr,
all i get on stderr with my patch is:
invalid accepts: (null) addr fe03601c size: 4
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886318
Title:
Qemu after v5.0.0 breaks macos guests
Status in
i get this over and over (and only this):
invalid size: acpi-tmr addr 0 size: 2
which seems to reside in hw/acpi/core.c
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886318
Title:
Qemu after
Hello all,
during unrelated work for splitting QTest from the TCG instruction counting
module,
I encountered what seems to be a migration stream issue, which is apparent only
on s390, and only shows in block test 267.
./check -qcow2 267
when it comes to snapshot save and load using backing
Emilio G. Cota writes:
> On Fri, Jul 10, 2020 at 14:03:27 -0700, Richard Henderson wrote:
>> On 7/9/20 7:13 AM, Alex Bennée wrote:
>> > Any write to a device might cause a re-arrangement of memory
>> > triggering a TLB flush and potential re-size of the TLB invalidating
>> > previous entries.
In that case please disregard those patches. Can you try this diff below
which will log any invalid accesses and see if anything appears on
stderr?
diff --git a/memory.c b/memory.c
index 9200b20130..5d1a6d4477 100644
--- a/memory.c
+++ b/memory.c
@@ -1354,10 +1354,12 @@ bool
Emilio G. Cota writes:
> On Thu, Jul 09, 2020 at 15:13:22 +0100, Alex Bennée wrote:
>> While there isn't any easy way to make the inline counts thread safe
>
> Why not? At least in 64-bit hosts TCG will emit a single write to
> update the 64-bit counter.
Well the operation is an add so that
No that doesn't make any difference either, nor does combining the two
patches :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886318
Title:
Qemu after v5.0.0 breaks macos guests
Status in
No worries - I didn't spot that those memory regions were implemented as
single-byte registers which means the access size won't matter anyway.
I had a quick look at your command line again and the only other obvious
thing I spotted was that a 64-bit access to the q35 "blackhole" region
might
101 - 113 of 113 matches
Mail list logo
