On 17/01/12 19:08, Peter Maydell wrote:
> On 15 January 2012 22:56, Christoffer Dall wrote:
>> On Fri, Jan 13, 2012 at 3:57 PM, Peter Maydell
>> wrote:
>>> PPS: these patches are against qemu-master so for kvm you'd need
>>> to (a) rebase them on qemu-linaro (b) put the kvm patches on top
>>> of
On 2013-08-14 09:16, Alexander Graf wrote:
On 14.08.2013, at 10:11, Marc Zyngier wrote:
On 2013-08-14 07:32, Alexander Graf wrote:
On 13.08.2013, at 20:03, Peter Maydell wrote:
These patches add support to target-arm for '-cpu host'.
The general semantics are the same as for ppc a
On 2013-08-14 07:32, Alexander Graf wrote:
On 13.08.2013, at 20:03, Peter Maydell wrote:
These patches add support to target-arm for '-cpu host'.
The general semantics are the same as for ppc and x86 (ie "whatever
the host kernel can support that looks basically like the host
CPU"), but the mec
On 19/01/16 13:32, Andrew Jones wrote:
> On Tue, Jan 19, 2016 at 01:43:41PM +0100, Christoffer Dall wrote:
>> On Tue, Jan 19, 2016 at 01:37:16PM +0100, Andrew Jones wrote:
>>> On Tue, Jan 19, 2016 at 12:49:18PM +0100, Christoffer Dall wrote:
The virt board has an arch timer, which is always on
On 20/01/16 14:01, Andrew Jones wrote:
> On Tue, Jan 19, 2016 at 07:48:14PM +0100, Andrew Jones wrote:
>> On Tue, Jan 19, 2016 at 01:43:07PM +0000, Marc Zyngier wrote:
>>>>> On Tue, Jan 19, 2016 at 01:37:16PM +0100, Andrew Jones wrote:
>>>> OK, CCing him.
On 20/01/16 15:06, Andrew Jones wrote:
> On Wed, Jan 20, 2016 at 02:28:05PM +0000, Marc Zyngier wrote:
>> On 20/01/16 14:01, Andrew Jones wrote:
>>> On Tue, Jan 19, 2016 at 07:48:14PM +0100, Andrew Jones wrote:
>>>> On Tue, Jan 19, 2016 at 01:43:07PM +, Marc Zyng
On 20/01/16 16:47, Andrew Jones wrote:
> On Wed, Jan 20, 2016 at 04:20:03PM +0000, Marc Zyngier wrote:
>> Just tried on Seattle with a 64bit guest, and there is hardly any
>> difference indeed. Both host and guest are "mostly" defconfig as well.
>> So there is a
Hi Gerd,
On 25/07/15 10:49, Gerd Hoffmann wrote:
> Hi,
>
>>> I agree. Also, as far as I understood Marc, his hope was that the fix to
>>> halfway working VGA emulation would be virtio-gpu.
>
> Note we have both virtio-vga and virtio-gpu-pci. virtio-vga has vga
> compatibility built-in, other
On 08/06/15 11:52, Peter Maydell wrote:
> On 8 June 2015 at 11:32, Igor Mammedov wrote:
>> On Thu, 4 Jun 2015 18:17:39 +0100
>> Peter Maydell wrote:
>>> On 4 June 2015 at 17:40, Shlomo Pongratz wrote:
>>> In order for it to work correctly we must use MPIDR values in
>>> the device tree which m
On 09/06/15 12:24, Peter Maydell wrote:
> On 9 June 2015 at 11:52, Marc Zyngier wrote:
>> On 08/06/15 11:52, Peter Maydell wrote:
>>> On 8 June 2015 at 11:32, Igor Mammedov wrote:
>>>> On Thu, 4 Jun 2015 18:17:39 +0100
>>>> Peter Maydell wrote:
>
On 09/06/15 14:16, Peter Maydell wrote:
> On 9 June 2015 at 13:27, Marc Zyngier wrote:
>> On 09/06/15 12:24, Peter Maydell wrote:
>>> So either:
>>> * QEMU needs to tell the kernel the MPIDR for each vCPU
>>> * QEMU needs to ask the kernel the MPIDR for ea
On 09/06/15 15:01, Peter Maydell wrote:
> On 9 June 2015 at 15:00, Marc Zyngier wrote:
>>
>> Yeah, what I had in mind was something along the lines of:
>> - kernel computes its "default MPDIR"
>> - kernel exposes a new capability "KVM_ARM_ALLOW_MPIDR_OV
On 10/06/15 10:54, Igor Mammedov wrote:
> On Tue, 09 Jun 2015 15:35:21 +0100
> Marc Zyngier wrote:
>
>> On 09/06/15 15:01, Peter Maydell wrote:
>>> On 9 June 2015 at 15:00, Marc Zyngier wrote:
>>>>
>>>> Yeah, what I had in mind was somethin
On 16/09/15 15:34, Alex Bennée wrote:
>
> liang yan writes:
>
>> Hello, All,
>>
>> I am trying to enable kvm for a guest vm on an APM X-Gene Host with
>> latest qemu, but could not make it work.
>>
>> The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64,
>>
>> Guest kernel is linux-
On 16/09/15 15:34, Alex Bennée wrote:
>
> liang yan writes:
>
>> Hello, All,
>>
>> I am trying to enable kvm for a guest vm on an APM X-Gene Host with
>> latest qemu, but could not make it work.
>>
>> The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64,
>>
>> Guest kernel is linux-
On Fri, 17 Jul 2015 10:30:38 +0100
Paolo Bonzini wrote:
>
>
> On 17/07/2015 06:44, Paolo Bonzini wrote:
> >
> >
> > On 16/07/2015 21:05, Richard W.M. Jones wrote:
> >>
> >> Sorry to spoil things, but I'm still seeing this bug, although it is
> >> now a lot less frequent with your patch. I wo
On Fri, 17 Jul 2015 14:39:55 +0100
Laszlo Ersek wrote:
> On 07/17/15 15:28, Marc Zyngier wrote:
> > On Fri, 17 Jul 2015 10:30:38 +0100
> > Paolo Bonzini wrote:
> >
> >>
> >>
> >> On 17/07/2015 06:44, Paolo Bonzini wrote:
> >>&g
On Fri, 17 Jul 2015 14:53:06 +0100
"Richard W.M. Jones" wrote:
> On Fri, Jul 17, 2015 at 02:48:40PM +0100, Marc Zyngier wrote:
> > Still: there is nothing in the registers that remotely points to that
> > area. X0 is the closest, but it'd take a big negative offset
On Fri, 17 Jul 2015 15:04:27 +0100
Paolo Bonzini wrote:
>
>
> On 17/07/2015 15:28, Marc Zyngier wrote:
> > >
> > > Marc, does it ring any bell?
> > Well, this is an example of a guest accessing non-memory using an
> > instruction that we cannot sa
On Tue, 21 Jul 2015 13:08:08 +0100
Alexander Graf wrote:
> On 07/20/15 21:06, Laszlo Ersek wrote:
> > Cc'ing Alex
> >
> > On 07/13/15 12:15, Paolo Bonzini wrote:
> >>
> >> On 13/07/2015 09:32, Gerd Hoffmann wrote:
> and virtio-vga is only compiled on 64-bit Intel?
> >>> There is virtio-gpu-p
On Wed, 23 Nov 2022 01:42:36 +,
chenxiang wrote:
>
> From: Xiang Chen
>
> Currently the number of MSI vectors comes from register PCI_MSI_FLAGS
> which should be power-of-2 in qemu, in some scenaries it is not the same as
> the number that driver requires in guest, for example, a PCI driver
On Wed, 23 Nov 2022 19:55:14 +,
Alex Williamson wrote:
>
> On Wed, 23 Nov 2022 12:08:05 +0000
> Marc Zyngier wrote:
>
> > On Wed, 23 Nov 2022 01:42:36 +,
> > chenxiang wrote:
> > >
> > > +static int vfio_pci_verify_msi_entry(struct vfio_pci
On Sat, 26 Nov 2022 06:33:15 +,
"chenxiang (M)" wrote:
>
>
> 在 2022/11/23 20:08, Marc Zyngier 写道:
> > On Wed, 23 Nov 2022 01:42:36 +,
> > chenxiang wrote:
> >> From: Xiang Chen
> >>
> >> Currently the number of MSI vectors co
On Wed, 30 Nov 2022 02:52:35 +,
"chenxiang (M)" wrote:
>
> Hi,
>
> We boot the VM using following commands (with nvdimm on) (qemu
> version 6.1.50, kernel 6.0-r4):
How relevant is the presence of the nvdimm? Do you observe the failure
without this?
>
> qemu-system-aarch64 -machine
> virt
On Wed, 03 Aug 2022 04:01:04 +0100,
Gavin Shan wrote:
>
> Hi Eric,
>
> On 8/2/22 7:41 PM, Eric Auger wrote:
> > On 8/2/22 08:45, Gavin Shan wrote:
> >> There are 3 highmem IO regions as below. They can be disabled in
> >> two situations: (a) The specific region is disabled by user. (b)
> >> The
On Wed, 03 Aug 2022 14:02:04 +0100,
Gavin Shan wrote:
>
> Hi Marc,
>
> On 8/3/22 5:01 PM, Marc Zyngier wrote:
> > On Wed, 03 Aug 2022 04:01:04 +0100,
> > Gavin Shan wrote:
> >> On 8/2/22 7:41 PM, Eric Auger wrote:
> >>> On 8/2/22 08:45, Gavin Shan
Hi Gavin,
On Thu, 11 Aug 2022 06:32:36 +0100,
Gavin Shan wrote:
>
> Hi Marc,
>
> On 8/8/22 7:17 PM, Marc Zyngier wrote:
> > On Wed, 03 Aug 2022 14:02:04 +0100,
> > Gavin Shan wrote:
[...]
> Sorry for the delay. I think the original changelog is confusing
> eno
Hi Peter,
On Fri, 12 Aug 2022 10:25:55 +0100,
Peter Maydell wrote:
>
> I've added some more relevant mailing lists to the cc.
>
> On Fri, 12 Aug 2022 at 09:45, Vitaly Chikunov wrote:
> > On Fri, Aug 12, 2022 at 05:14:27AM +0300, Vitaly Chikunov wrote:
> > > I noticed that we starting to get ma
On Fri, 12 Aug 2022 10:25:55 +0100,
Peter Maydell wrote:
>
> I've added some more relevant mailing lists to the cc.
>
> On Fri, 12 Aug 2022 at 09:45, Vitaly Chikunov wrote:
> > On Fri, Aug 12, 2022 at 05:14:27AM +0300, Vitaly Chikunov wrote:
> > > I noticed that we starting to get many errors l
On 2024-02-09 18:57, Peter Maydell wrote:
On Fri, 9 Feb 2024 at 16:00, Eric Auger wrote:
This series adds ARM Nested Virtualization support in KVM mode.
This is a respin of previous contributions from Miguel [1] and Haibo
[2].
This was tested with Marc's v11 [3] on Ampere HW with fedora L1
Hi Peter,
On 12/03/2019 10:08, Peter Maydell wrote:
> On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
>>
>> When we stop a VM for more than 30 seconds and then resume it, by qemu
>> monitor command "stop" and "cont", Linux on VM will complain of "soft
>> lockup - CPU#x stuck for xxs!" as below:
>>
Hi Gavin,
On 2020-02-14 05:59, Gavin Shan wrote:
This supports SError injection, which will be used by "virt" board to
simulating the behavior of NMI injection in next patch. As Peter
Maydell
suggested, this adds a new interrupt (ARM_CPU_SERROR), which is
parallel
to CPU_INTERRUPT_HARD. The b
On 2020-02-18 02:04, Gavin Shan wrote:
This supports SError injection, which will be used by "virt" board to
simulating the behavior of NMI injection in next patch. As Peter
Maydell
suggested, this adds a new interrupt (ARM_CPU_SERROR), which is
parallel
to CPU_INTERRUPT_HARD. The backend depe
On Wed, 19 Feb 2020 10:09:39 +1100
Gavin Shan wrote:
> Hi Marc,
>
> On 2/19/20 3:28 AM, Marc Zyngier wrote:
> > On 2020-02-18 02:04, Gavin Shan wrote:
> >> This supports SError injection, which will be used by "virt" board to
> >> simulating the
On 2020-02-20 06:01, Gavin Shan wrote:
Currently, PL011 is used by ARM virt board by default. It's possible to
block the system from booting. With below parameters in command line,
the
backend could run into endless attempts of transmitting packets, which
can't succeed because of running out of
Hi Gavin,
On 2020-02-21 04:24, Gavin Shan wrote:
Hi Peter and Marc,
On 2/20/20 9:10 PM, Peter Maydell wrote:
On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote:
On 2020-02-20 06:01, Gavin Shan wrote:
This fixes the issue by using newly added API
qemu_chr_fe_try_write_all(),
which provides
On 2019-12-06 14:08, Peter Maydell wrote:
On Sun, 1 Dec 2019 at 12:20, Marc Zyngier wrote:
HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to
EL2, and HCR_EL2.TID0 does the same for reads of FPSID.
In order to handle this, introduce a new TCG helper function that
checks for
On 2019-12-06 14:13, Peter Maydell wrote:
On Sun, 1 Dec 2019 at 12:20, Marc Zyngier wrote:
Hi all,
This series is a follow-up on [1], which tried to address the
remaining missing HCR_EL2.TIDx traps. I've hopefully now adressed
the
comments that Peter and Edgar raised.
I've als
On 2019-12-16 15:33, Peter Maydell wrote:
On Thu, 12 Dec 2019 at 17:33, Andrew Jones
wrote:
Userspace that wants to set KVM_REG_ARM_TIMER_CNT should beware that
the KVM register ID is not correct. This cannot be fixed because
it's
UAPI and if the UAPI headers are used then it can't be a pr
On 2019-12-16 16:59, Andrew Jones wrote:
On Mon, Dec 16, 2019 at 04:18:23PM +, Marc Zyngier wrote:
On 2019-12-16 15:33, Peter Maydell wrote:
> On Thu, 12 Dec 2019 at 17:33, Andrew Jones
wrote:
>
> > Userspace that wants to set KVM_REG_ARM_TIMER_CNT should beware
that
ok at its own interrupt state actually sees the guest
state, which is unexpected and breaks KVM as of Linux 5.3.
Instead, check for the running EL and return the physical bits
if not running in a virtualized context.
Fixes: 636540e9c40b
Reported-by: Quentin Perret
Signed-off-by: Marc Zy
eally* isn't supported.
Do the right thing by trapping to EL2 if HCR_EL2.TID3 is set.
Reported-by: Will Deacon
Signed-off-by: Marc Zyngier
---
There is a number of other trap bits missing (TID[0-2], for example),
but this at least gets a mainline Linux going with cpu=max.
target/arm/hel
On 2019-11-25 10:40, Will Deacon wrote:
On Sat, Nov 23, 2019 at 11:56:18AM +, Marc Zyngier wrote:
HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this
requirement.
This breaks (among other things) KVM guests that have
On 2019-11-25 16:21, Peter Maydell wrote:
On Sat, 23 Nov 2019 at 11:56, Marc Zyngier wrote:
HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this
requirement.
This breaks (among other things) KVM guests that have PtrAuth
On 2019-11-25 17:27, Peter Maydell wrote:
On Mon, 25 Nov 2019 at 17:08, Marc Zyngier wrote:
On 2019-11-25 16:21, Peter Maydell wrote:
> Missing .accessfn for ID_AA4PFR2_EL1_RESERVED ?
Indeed, I oversaw that one. I'll fix it and repost it together with
the extra patches to handle
On 2019-11-26 21:04, Richard Henderson wrote:
On 11/23/19 11:56 AM, Marc Zyngier wrote:
HCR_EL2.TID3 mandates that access from EL1 to a long list of id
registers traps to EL2, and QEMU has so far ignored this
requirement.
This breaks (among other things) KVM guests that have PtrAuth
enabled
of KVM/arm64 that sets the control
bits for 32bit guests.
Signed-off-by: Marc Zyngier
---
target/arm/helper-a64.h| 2 ++
target/arm/internals.h | 8
target/arm/translate-vfp.inc.c | 12 +---
target/arm/vfp_helper.c| 27 +++
4
d it seems to generate an exception.
It isn't like anyone is going to miss it, but I wonder if
it should be implemented... It could also be that I'm missing
the obvious and that my testing is broken! ;-)
Marc Zyngier (3):
target/arm: Honor HCR_EL2.TID2 trapping requirements
target/arm
On 2019-11-28 16:30, Peter Maydell wrote:
On Thu, 28 Nov 2019 at 16:17, Marc Zyngier wrote:
I started looking the rest of the missing TIDx handling,
and this resulted in the following patches.
There is still one thing I'm a bit puzzled by though:
HCR_EL2.TID0 mandates trapping o
-by: Marc Zyngier
---
target/arm/helper.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 0bf8f53d4b..0b6887b100 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1910,6 +1910,17 @@ static
trapping to EL2 if HCR_EL2.TID1 is set.
Signed-off-by: Marc Zyngier
---
target/arm/helper.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 0b6887b100..9bff769692 100644
--- a/target/arm/helper.c
Hi Peter,
Thanks for having a look at this.
On 2019-11-28 16:43, Peter Maydell wrote:
On Thu, 28 Nov 2019 at 16:17, Marc Zyngier wrote:
HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to
EL2, and that HCR_EL2.TID0 does the same for reads of FPSID.
In order to handle this
On 2019-11-29 08:28, Edgar E. Iglesias wrote:
On Thu, Nov 28, 2019 at 04:17:18PM +, Marc Zyngier wrote:
HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to
EL2, and that HCR_EL2.TID0 does the same for reads of FPSID.
In order to handle this, introduce a new TCG helper
pping
of JIDR to EL2 using HCR_EL2.TID0. Yay, Christmas! ;-)
I'm now going back to kernel stuff. I swear!
[1] https://patchew.org/QEMU/20191128161718.24361-1-...@kernel.org/
Marc Zyngier (5):
target/arm: Honor HCR_EL2.TID2 trapping requirements
target/arm: Honor HCR_EL2.TID1 trapping requirem
QEMU lacks the minimum Jazelle implementation that is required
by the architecture (everything is RAZ or RAZ/WI). Add it
together with the HCR_EL2.TID0 trapping that goes with it.
Signed-off-by: Marc Zyngier
---
target/arm/helper.c | 27 +++
1 file changed, 27 insertions
-off-by: Marc Zyngier
---
target/arm/helper.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 0bf8f53d4b..1e546096b8 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1910,6 +1910,17
never HSTR_EL2 is non-zero and that QEMU translates
a context where this trap has a chance to apply, and only generate
the extra access check if the hypervisor is actively using this feature.
Tested with a hand-crafted KVM guest accessing CBAR.
Signed-off-by: Marc Zyngier
---
target/arm/cpu.h
KVM/arm64 that sets the control
bits for 32bit guests.
Reviewed-by: Edgar E. Iglesias
Signed-off-by: Marc Zyngier
---
target/arm/helper-a64.h| 2 ++
target/arm/translate-vfp.inc.c | 18 +++---
target/arm/vfp_helper.c| 29 +
3 files changed
trapping to EL2 if HCR_EL2.TID1 is set.
Reviewed-by: Edgar E. Iglesias
Signed-off-by: Marc Zyngier
---
target/arm/helper.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 1e546096b8..93ecab27c0
On 2019-12-02 15:35, Richard Henderson wrote:
On 12/1/19 12:20 PM, Marc Zyngier wrote:
HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to
EL2, and HCR_EL2.TID0 does the same for reads of FPSID.
In order to handle this, introduce a new TCG helper function that
checks for these
On 2019-12-02 16:56, Richard Henderson wrote:
On 12/2/19 4:45 PM, Marc Zyngier wrote:
Annoying that there's a bug in the manual -- FPSID is listed as
group 0 in
plenty of places, except in the pseudo-code for Accessing the FPSID
which uses TID3.
Are you sure? I'm looking at
t;> $ echo " [ ...]"
>>"[, [ ...]] ...]"
>> > /sys/bus/platform/drivers/gpio-virt-agg/new_device
>>
>> Likewise, virtual GPIO controllers can be destroyed after use:
>>
>> $ echo gpio-virt-agg. \
>>
On Tue, 4 Feb 2020 14:51:39 +1100
Gavin Shan wrote:
[...]
> The mechanism I figured out is to inject SError to guest, as below snippet
> shows. It
> helps to get a panic and guest rebooting, which looks similar to what x86/p
> pc have.
I think being able to inject a SError is a reasonable thin
Hi Heyi,
On 2020-02-04 08:26, Heyi Guo wrote:
Update Marc's email address.
+cc Gavin as he is posting a RFC for ARM NMI.
Hi Marc,
Really sorry for missing to update your email address, for the initial
topic was raised long time ago and I forgot to update the Cc list in
the commit message of t
On 2020-02-06 01:20, Heyi Guo wrote:
Hi Marc,
On 2020/2/5 21:15, Marc Zyngier wrote:
Hi Heyi,
On 2020-02-04 08:26, Heyi Guo wrote:
Update Marc's email address.
+cc Gavin as he is posting a RFC for ARM NMI.
Hi Marc,
Really sorry for missing to update your email address, for the
in
any other interrupt,
and is quite happy to carry an active bit that eventually gets exposed
to the hypervisor.
I don't think this ever caused any issue, but I'd be pretty happy to
see the QEMU implementation fixed.
For the whole series:
Reviewed-by: Marc Zyngier
Thanks,
M.
On Thu, 23 Jun 2022 14:10:17 +0100,
Andrew Jones wrote:
>
> As a side effect of leaving Red Hat I won't be able to use my Red Hat
> email address anymore. I'm also changing the name of my gitlab group.
>
> Signed-off-by: Andrew Jones
> Signed-off-by: Andrew Jo
Just like we can control the enablement of the highmem PCIe region
using highmem_ecam, let's add a control for the highmem GICv3
redistributor region.
Similarily to highmem_ecam, these redistributors are disabled when
highmem is off.
Signed-off-by: Marc Zyngier
---
hw/arm/virt-acpi-build.
-off-by: Marc Zyngier
---
hw/arm/virt.c | 46 +++---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9d2abdbd5f..a572e0c9d9 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1610,10 +1610,10 @@ static
Currently, the highmem PCIe region is oddly keyed on the highmem
attribute instead of highmem_ecam. Move the enablement of this PCIe
region over to highmem_ecam.
Signed-off-by: Marc Zyngier
---
hw/arm/virt-acpi-build.c | 10 --
hw/arm/virt.c| 4 ++--
2 files changed, 6
ghmem PCIe and GICv3 RDs when they are outside of the
PA range
This has been tested on an M1-based Mac-mini running Linux v5.15-rc3.
[1] https://lore.kernel.org/r/2021082211.1290891-1-...@kernel.org
Marc Zyngier (5):
hw/arm/virt: Key enablement of highmem PCIe on highmem_ecam
hw/arm/v
Make sure both the highmem PCIe and GICv3 regions are disabled when
they don't fully fit in the PA range.
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a572e0c9d9..756f67b6c8 100644
--- a/hw/arm/v
range, as the reported IPA space is larger than
what it should be.
Instead, honor the user-specified limit to only use the devices
at the lowest end of the spectrum, and fail if we have memory
crossing the 4GiB limit.
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 9 -
1 file changed
In order to only keep the highmem devices that actually fit in
the PA range, check their location against the range and update
highest_gpa if they fit. If they don't, mark them as disabled.
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 34 --
1 file change
ck before we compute the memory map
- Drop useless MAX() when computing highest_gpa
- Fixed more deviations from the QEMU coding style
- Collected Eric's RBs, with thanks
[1]: https://lore.kernel.org/r/20220107163324.2491209-1-...@kernel.org
Marc Zyngier (6):
hw/arm/virt: Add a co
-off-by: Marc Zyngier
---
hw/arm/virt.c | 64 +--
1 file changed, 52 insertions(+), 12 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ecc3e3e5b0..a427676b50 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1660,7 +1660,7 @@ static
range, as the reported IPA space is larger than
what it should be.
Instead, honor the user-specified limit to only use the devices
at the lowest end of the spectrum, and fail if we have memory
crossing the 4GiB limit.
Reviewed-by: Andrew Jones
Reviewed-by: Eric Auger
Signed-off-by: Marc Zyngier
Just like we can control the enablement of the highmem PCIe region
using highmem_ecam, let's add a control for the highmem GICv3
redistributor region.
Similarily to highmem_ecam, these redistributors are disabled when
highmem is off.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zy
Just like we can control the enablement of the highmem PCIe ECAM
region using highmem_ecam, let's add a control for the highmem
PCIe MMIO region.
Similarily to highmem_ecam, this region is disabled when highmem
is off.
Signed-off-by: Marc Zyngier
---
hw/arm/virt-acpi-build.c
Now that the devices present in the extended memory map are checked
against the available PA space and disabled when they don't fit,
there is no need to keep the same checks against highmem, as
highmem really is a shortcut for the PA space being 32bit.
Reviewed-by: Eric Auger
Signed-off-by:
On 2022-01-26 02:59, Philippe Mathieu-Daudé via wrote:
Hi,
On 26/1/22 00:59, Kenneth Adam Miller wrote:
Hello all,
I would like to emulate something on a pi so that I don't have to
pay as high of a translation penalty since the guest and host will
share the same arch. I'm finding that on som
Hi Eric,
On Tue, 04 Jan 2022 15:31:33 +,
Eric Auger wrote:
>
> Hi Marc,
>
> On 12/27/21 4:53 PM, Marc Zyngier wrote:
> > Hi Eric,
> >
> > Picking this up again after a stupidly long time...
> >
> > On Mon, 04 Oct 2021 13:00:21 +0100,
> > Er
Hi Richard,
On Wed, 05 Jan 2022 21:36:55 +,
Richard Henderson wrote:
>
> On 1/3/22 10:05 AM, Marc Zyngier wrote:
> > -/*
> > - * KVM does not support modifications to this feature.
> > - * We have not registered the cpu properties when KVM
&
On Thu, 06 Jan 2022 17:20:33 +,
Richard Henderson wrote:
>
> On 1/6/22 1:16 AM, Marc Zyngier wrote:
> >>> +static bool kvm_arm_pauth_supported(void)
> >>> +{
> >>> +return (kvm_check_extension(kvm_state, KVM_CAP_ARM_PTRAUTH_ADDRESS)
>
On Thu, 06 Jan 2022 18:26:29 +,
Richard Henderson wrote:
>
> Mm. It does beg the question of why KVM exposes multiple bits. If
> they must be tied, then it only serves to make the interface more
> complicated than necessary. We would be better served to have a
> single bit to control all o
Hi Eric,
On Wed, 05 Jan 2022 09:41:19 +,
Eric Auger wrote:
>
> couldn't you simply introduce highmem_redist which is truly missing. You
> could set it in virt_set_memmap() in case you skip extended_map overlay
> and use it in virt_gicv3_redist_region_count() as you did?
> In addition to the
On Wed, 05 Jan 2022 09:22:39 +,
Eric Auger wrote:
>
> Hi Marc,
>
> On 12/27/21 10:16 PM, Marc Zyngier wrote:
> > Even when the VM is configured with highmem=off, the highest_gpa
> > field includes devices that are above the 4GiB limit.
> > Similarily, nothing
;pauth' comment is removed from cpu-features.rst,
as it is now common to both TCG and KVM.
Tested on an Apple M1 running 5.16-rc6.
Cc: Eric Auger
Cc: Richard Henderson
Cc: Peter Maydell
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zyngier
---
* From v2:
- Fixed indentation and s
can use the highmem redist
and PCIe ECAM ranges, but not the high PCIe range.
- Dropped some of Andrew's RBs, as the code significantly changed.
[1] https://lore.kernel.org/r/20211227211642.994461-1-...@kernel.org
Marc Zyngier (6):
hw/arm/virt: Add a control for the the highmem PCIe
Just like we can control the enablement of the highmem PCIe region
using highmem_ecam, let's add a control for the highmem GICv3
redistributor region.
Similarily to highmem_ecam, these redistributors are disabled when
highmem is off.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zy
-off-by: Marc Zyngier
---
hw/arm/virt.c | 53 ---
1 file changed, 46 insertions(+), 7 deletions(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 57c55e8a37..db4b0636e1 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1660,7 +1660,7 @@ static
range, as the reported IPA space is larger than
what it should be.
Instead, honor the user-specified limit to only use the devices
at the lowest end of the spectrum, and fail if we have memory
crossing the 4GiB limit.
Reviewed-by: Andrew Jones
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 10
Just like we can control the enablement of the highmem PCIe ECAM
region using highmem_ecam, let's add a control for the highmem
PCIe MMIO region.
Similarily to highmem_ecam, this region is disabled when highmem
is off.
Signed-off-by: Marc Zyngier
---
hw/arm/virt-acpi-build.c
Now that the devices present in the extended memory map are checked
against the available PA space and disabled when they don't fit,
there is no need to keep the same checks against highmem, as
highmem really is a shortcut for the PA space being 32bit.
Signed-off-by: Marc Zyngier
---
h
In order to only keep the highmem devices that actually fit in
the PA range, check their location against the range and update
highest_gpa if they fit. If they don't, mark them them as disabled.
Signed-off-by: Marc Zyngier
---
hw/arm/virt.c | 34 --
1
Hi Eric,
On Fri, 07 Jan 2022 17:15:19 +,
Eric Auger wrote:
>
> Hi Marc,
>
> On 1/6/22 10:26 PM, Marc Zyngier wrote:
> > On Wed, 05 Jan 2022 09:22:39 +,
> > Eric Auger wrote:
> >> Hi Marc,
> >>
> >> On 12/27/21 10:16 PM, Marc Zyngi
On Fri, 07 Jan 2022 18:48:16 +,
Peter Maydell wrote:
>
> On Fri, 7 Jan 2022 at 18:18, Marc Zyngier wrote:
> > This is a chicken and egg problem: you need the IPA size to compute
> > the memory map, and you need the memory map to compute the IPA
> > size. Fun, isn
On 2022-01-07 20:23, Richard Henderson wrote:
On 1/7/22 7:01 AM, Marc Zyngier wrote:
@@ -1380,17 +1380,10 @@ void arm_cpu_finalize_features(ARMCPU *cpu,
Error **errp)
return;
}
-/*
- * KVM does not support modifications to this feature.
- * We
Hi Eric,
On Mon, 10 Jan 2022 15:35:44 +,
Eric Auger wrote:
>
> Hi Marc,
>
> On 1/7/22 5:33 PM, Marc Zyngier wrote:
[...]
> > @@ -190,7 +191,8 @@ static inline int
> > virt_gicv3_redist_region_count(VirtMachineState *vms)
> >
> > assert(vm
On Mon, 10 Jan 2022 15:38:56 +,
Eric Auger wrote:
>
> Hi Marc,
>
> On 1/7/22 5:33 PM, Marc Zyngier wrote:
> > The highmem attribute is nothing but another way to express the
> > PA range of a VM. To support HW that has a smaller PA range then
> > what QEMU assu
1 - 100 of 250 matches
Mail list logo
