Hi Marc,
On Thu, Jan 06, 2022 at 06:16:04PM +, Marc Zyngier wrote:
> On Thu, 06 Jan 2022 11:54:11 +,
> Alexandru Elisei wrote:
> >
> > Hi Marc,
> >
> > On Tue, Dec 14, 2021 at 12:28:15PM +, Marc Zyngier wrote:
> > > On Mon, 13 Dec 2021 15:23:08 +,
> > > Alexandru Elisei wrote:
Hi Paolo,
Here's the bulk of the KVM/arm64 updates for 5.17. No real new feature
this time around, but a bunch of changes that will make the merging of
upcoming features easier (pKVM is reaching a point where it will
finally be usable, and NV isn't too far off... fingers crossed). This
comes with
> > These are the type of pages which KVM is currently rejecting. Is this
> > something that KVM can support?
>
> I'm not opposed to it. My complaint is that this series is incomplete in
> that it
> allows mapping the memory into the guest, but doesn't support accessing the
> memory
> from KVM i
Hi Marc,
On Tue, Jan 04, 2022 at 02:39:59PM +, Marc Zyngier wrote:
> On Mon, 15 Nov 2021 16:57:05 +,
> Alexandru Elisei wrote:
> >
> > The KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_V3_SET_PMU) VCPU ioctl is
> > used to assign a physical PMU to the events that KVM creates when emulating
>
On Fri, 07 Jan 2022 11:08:05 +,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On Thu, Jan 06, 2022 at 06:16:04PM +, Marc Zyngier wrote:
> > On Thu, 06 Jan 2022 11:54:11 +,
> > Alexandru Elisei wrote:
> > >
> > > 2. What's to stop userspace to change the PMU after at least one VCPU has
>
Add basic support for Pointer Authentication when running a KVM
guest and that the host supports it, loosely based on the SVE
support.
Although the feature is enabled by default when the host advertises
it, it is possible to disable it by setting the 'pauth=off' CPU
property. The 'pauth' comment i
On 1/7/22 12:45, Marc Zyngier wrote:
Hi Paolo,
Here's the bulk of the KVM/arm64 updates for 5.17. No real new feature
this time around, but a bunch of changes that will make the merging of
upcoming features easier (pKVM is reaching a point where it will
finally be usable, and NV isn't too far of
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 | 10 --
h
Here's another stab at enabling QEMU on systems with pathologically
reduced IPA ranges such as the Apple M1 (previous version at [1]).
Eventually, we're able to run a KVM guest with more than just 3GB of
RAM on a system with a 36bit IPA space, and at most 123 vCPUs.
This also addresses some pathol
Even when the VM is configured with highmem=off, the highest_gpa
field includes devices that are above the 4GiB limit.
Similarily, nothing seem to check that the memory is within
the limit set by the highmem=off option.
This leads to failures in virt_kvm_type() on systems that have
a crippled IPA
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
---
hw/arm/virt
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 file changed
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 assumes, pass this PA range to the virt_set_memmap()
function, allowing it to correctly exclude highmem devices
if they are outside of the PA range.
Signed-off
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 Zyngier
---
hw
Hi Marc,
On 1/6/22 8:34 PM, Marc Zyngier wrote:
> 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
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 Zyngier wrote:
>>> Even when the VM is configured with highmem=off, the highest_gpa
>>> field includes devices that are above the 4GiB limit.
>>>
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 Zyngier wrote:
> >>> Even when the VM is configured with high
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't it?
>
> At the moment, virt_set_memmap() doesn't know about the IPA space,
> generates a highes
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't it?
> >
> > At the moment,
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 have not registered the cpu properties when KV
20 matches
Mail list logo
