Make sure GICV physical address is placed at a 4Kb boundary as spec
says, not host kernel's page boundary. This prevents !4Kb kernels from
returning an ENXIO prematurely during the KVM init phase at boot.
Tested on Overdrive 3000 with 64Kb page-size kernel with ACPI.
Signed-off-by: Itaru Kitaya
> -Original Message-
> From: kvmarm-boun...@lists.cs.columbia.edu [mailto:kvmarm-
> boun...@lists.cs.columbia.edu] On Behalf Of Andre Przywara
> Sent: Tuesday, June 28, 2016 6:02 PM
> To: Marc Zyngier ; Christoffer Dall
> ; Eric Auger
> Cc: linux-arm-ker...@lists.infradead.org; kvmarm@li
On Tue, Jun 07, 2016 at 11:58:35AM +0100, Marc Zyngier wrote:
> This is more of a safety measure than anything else: If we end-up
> with an idmap page that intersect with the range picked for the
> the HYP VA space, abort the KVM setup, as it is unsafe to go
> further.
>
> I cannot imagine it happ
On Tue, Jun 07, 2016 at 11:58:32AM +0100, Marc Zyngier wrote:
> Just like for arm64, we can now make the HYP setup a lot simpler,
> and we can now initialise it in one go (instead of the two
> phases we currently have).
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm/include/asm/kvm_host.h | 15
On Tue, Jun 07, 2016 at 11:58:28AM +0100, Marc Zyngier wrote:
> We're in a position where we can now always have "merged" page
> tables, where both the runtime mapping and the idmap coexist.
>
> This results in some code being removed, but there is more to come.
>
> Signed-off-by: Marc Zyngier
>
On Tue, Jun 07, 2016 at 11:58:29AM +0100, Marc Zyngier wrote:
> Now that we only have the "merged page tables" case to deal with,
> there is a bunch of things we can simplify in the HYP code (both
> at init and teardown time).
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/include/asm/kvm_ho
On 06/28/2016 12:55 PM, Laszlo Ersek wrote:
On 06/27/16 12:34, Christoffer Dall wrote:
On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Biesheuvel wrote:
So first of all, let me reiterate that I could only find a single
instance in QEMU where a PCI MMIO region is backed by host memory,
which is
On Tue, Jun 28, 2016 at 02:25:19PM +0100, Catalin Marinas wrote:
> On Tue, Jun 28, 2016 at 03:19:14PM +0200, Ard Biesheuvel wrote:
> > On 28 June 2016 at 15:10, Catalin Marinas wrote:
> > > On Tue, Jun 28, 2016 at 02:20:43PM +0200, Christoffer Dall wrote:
> > >> On Tue, Jun 28, 2016 at 01:06:36PM
(adding Gerd)
On 06/28/16 15:14, Ard Biesheuvel wrote:
> In any case, reconciling software that requires a framebuffer with a
> GPU emulation that does not expose one by design is going to be
> problematic even without this issue. How is this supposed to work on
> x86?
AFAIK:
"virtio-gpu-pci" i
On Tue, Jun 28, 2016 at 03:19:14PM +0200, Ard Biesheuvel wrote:
> On 28 June 2016 at 15:10, Catalin Marinas wrote:
> > On Tue, Jun 28, 2016 at 02:20:43PM +0200, Christoffer Dall wrote:
> >> On Tue, Jun 28, 2016 at 01:06:36PM +0200, Laszlo Ersek wrote:
> >> > On 06/28/16 12:04, Christoffer Dall wro
On 28 June 2016 at 15:10, Catalin Marinas wrote:
> On Tue, Jun 28, 2016 at 02:20:43PM +0200, Christoffer Dall wrote:
>> On Tue, Jun 28, 2016 at 01:06:36PM +0200, Laszlo Ersek wrote:
>> > On 06/28/16 12:04, Christoffer Dall wrote:
>> > > On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrot
On 28 June 2016 at 12:55, Laszlo Ersek wrote:
> On 06/27/16 12:34, Christoffer Dall wrote:
>> On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Biesheuvel wrote:
>
>>> So first of all, let me reiterate that I could only find a single
>>> instance in QEMU where a PCI MMIO region is backed by host memor
On Tue, Jun 28, 2016 at 02:20:43PM +0200, Christoffer Dall wrote:
> On Tue, Jun 28, 2016 at 01:06:36PM +0200, Laszlo Ersek wrote:
> > On 06/28/16 12:04, Christoffer Dall wrote:
> > > On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrote:
> > >> So if vga-pci.c is the only problematic devic
On Tue, Jun 07, 2016 at 11:58:25AM +0100, Marc Zyngier wrote:
> As we move towards a selectable HYP VA range, it is obvious that
> we don't want to test a variable to find out if we need to use
> the bottom VA range, the top VA range, or use the address as is
> (for VHE).
>
> Instead, we can expan
Now that all ITS emulation functionality is in place, we advertise
MSI functionality to userland and also the ITS device to the guest - if
userland has configured that.
Signed-off-by: Andre Przywara
---
Documentation/virtual/kvm/api.txt | 2 +-
arch/arm64/kvm/Kconfig| 1 +
arch/arm
When userland wants to inject a MSI into the guest, it uses the
KVM_SIGNAL_MSI ioctl, which carries the doorbell address along with
the payload and the device ID.
We convert this into an MMIO write to the ITS translation register,
so we can use the knowledge of the kvm_io_bus framework about the
di
Add emulation for some basic MMIO registers used in the ITS emulation.
This includes:
- GITS_{CTLR,TYPER,IIDR}
- ID registers
- GITS_{CBASER,CREADR,CWRITER}
(which implement the ITS command buffer handling)
- GITS_BASER
Most of the handlers are pretty straight forward, only the CWRITER
handler i
The LPI pending status for a GICv3 redistributor is held in a table
in (guest) memory. To achieve reasonable performance, we cache this
data in our struct vgic_irq. The initial pending state must be read
from guest memory upon enabling LPIs for this redistributor.
Signed-off-by: Andre Przywara
--
The connection between a device, an event ID, the LPI number and the
allocated CPU is stored in in-memory tables in a GICv3, but their
format is not specified by the spec. Instead software uses a command
queue in a ring buffer to let the ITS implementation use their own
format.
Implement handlers f
In the moment our struct vgic_irq's are statically allocated at guest
creation time. So getting a pointer to an IRQ structure is trivial and
safe. LPIs are more dynamic, they can be mapped and unmapped at any time
during the guest's _runtime_.
In preparation for supporting LPIs we introduce referen
The (system-wide) LPI configuration table is held in a table in
(guest) memory. To achieve reasonable performance, we cache this data
in our struct vgic_irq. If the guest updates the configuration data
(which consists of the enable bit and the priority value), it issues
an INV or INVALL command to
Introduce a new KVM device that represents an ARM Interrupt Translation
Service (ITS) controller. Since there can be multiple of this per guest,
we can't piggy back on the existing GICv3 distributor device, but create
a new type of KVM device.
On the KVM_CREATE_DEVICE ioctl we allocate and initiali
LPIs are dynamically created (mapped) at guest runtime and their
actual number can be quite high, but is mostly assigned using a very
sparse allocation scheme. So arrays are not an ideal data structure
to hold the information.
We use a spin-lock protected linked list to hold all mapped LPIs,
repres
In the GICv3 redistributor there are the PENDBASER and PROPBASER
registers which we did not emulate so far, as they only make sense
when having an ITS. In preparation for that emulate those MMIO
accesses by storing the 64-bit data written into it into a variable
which we later read in the ITS emula
The ARM GICv3 ITS emulation code goes into a separate file, but needs
to be connected to the GICv3 emulation, of which it is an option.
The ITS MMIO handlers require the respective ITS pointer to be passed in,
so we amend the existing VGIC MMIO framework to let it cope with that.
Also we introduce
KVM capabilities can be a per-VM property, though ARM/ARM64 currently
does not pass on the VM pointer to the architecture specific
capability handlers.
Add a "struct kvm*" parameter to those function to later allow proper
per-VM capability reporting.
Signed-off-by: Andre Przywara
Reviewed-by: Eri
kvm_register_device_ops() can return an error, so lets check its return
value and propagate this up the call chain.
Signed-off-by: Andre Przywara
---
virt/kvm/arm/vgic/vgic-kvm-device.c | 15 +--
virt/kvm/arm/vgic/vgic-v2.c | 7 ++-
virt/kvm/arm/vgic/vgic-v3.c |
The kvm_io_bus framework is a nice place of holding information about
various MMIO regions for kernel emulated devices.
Add a call to retrieve the kvm_io_device structure which is associated
with a certain MMIO address. This avoids to duplicate kvm_io_bus'
knowledge of MMIO regions without having t
The ARM GICv3 ITS MSI controller requires a device ID to be able to
assign the proper interrupt vector. On real hardware, this ID is
sampled from the bus. To be able to emulate an ITS controller, extend
the KVM MSI interface to let userspace provide such a device ID. For
PCI devices, the device ID
arm-gic-v3.h contains bit and register definitions for the GICv3 and ITS,
at least for the bits the we currently care about.
The ITS emulation needs more definitions, so add them and refactor
the memory attribute #defines to be more universally usable.
To avoid changing all users, we still provide
Logically a GICv3 redistributor is assigned to a (v)CPU, so we should
aim to keep redistributor related variables out of our struct vgic_dist.
Let's start by replacing the redistributor related kvm_io_device array
with two members in our existing struct vgic_cpu, which are naturally
per-VCPU and t
Hi,
another try on the KVM ITS emulation support.
It allows those KVM guests that use an emulated GICv3 to use LPIs as
well, though in the moment this is limited to emulated PCI devices.
This is based on kvm-arm-for-v4.7-rc2 and relies on the new VGIC
implementation.
Compared to the last drop the
On Tue, Jun 28, 2016 at 01:06:36PM +0200, Laszlo Ersek wrote:
> On 06/28/16 12:04, Christoffer Dall wrote:
> > On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrote:
> >> On 27 June 2016 at 15:35, Christoffer Dall
> >> wrote:
> >>> On Mon, Jun 27, 2016 at 02:30:46PM +0200, Ard Biesheuvel
On Mon, Jun 27, 2016 at 03:20:23PM +0100, Marc Zyngier wrote:
> On 27/06/16 14:47, Christoffer Dall wrote:
> > On Tue, Jun 07, 2016 at 11:58:22AM +0100, Marc Zyngier wrote:
> >> HYP_PAGE_OFFSET is not massively useful. And the way we use it
> >> in KERN_HYP_VA is inconsistent with the equivalent op
On Mon, Jun 27, 2016 at 03:06:11PM +0100, Marc Zyngier wrote:
> On 27/06/16 14:28, Christoffer Dall wrote:
> > On Tue, Jun 07, 2016 at 11:58:21AM +0100, Marc Zyngier wrote:
> >> Since dealing with VA ranges tends to hurt my brain badly, let's
> >> start with a bit of documentation that will hopeful
On 06/28/16 12:04, Christoffer Dall wrote:
> On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrote:
>> On 27 June 2016 at 15:35, Christoffer Dall
>> wrote:
>>> On Mon, Jun 27, 2016 at 02:30:46PM +0200, Ard Biesheuvel wrote:
On 27 June 2016 at 12:34, Christoffer Dall
wrote:
>>
On 06/27/16 16:29, Alexander Graf wrote:
>
>
>> Am 27.06.2016 um 15:57 schrieb Ard Biesheuvel :
>>
>>> On 27 June 2016 at 15:35, Christoffer Dall
>>> wrote:
On Mon, Jun 27, 2016 at 02:30:46PM +0200, Ard Biesheuvel wrote:
> On 27 June 2016 at 12:34, Christoffer Dall
> wrote:
>
On 06/27/16 12:34, Christoffer Dall wrote:
> On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Biesheuvel wrote:
>> So first of all, let me reiterate that I could only find a single
>> instance in QEMU where a PCI MMIO region is backed by host memory,
>> which is vga-pci.c. I wonder of there are any o
On Mon, Jun 27, 2016 at 03:10:20PM +0100, Peter Maydell wrote:
> On 27 June 2016 at 14:49, Mark Rutland wrote:
> > On Mon, Jun 27, 2016 at 02:15:29PM +0100, Peter Maydell wrote:
> >> I get the impression dma-coherent is the right thing to advertise
> >> anyway. Do you have the documentation to han
On Mon, Jun 27, 2016 at 03:57:28PM +0200, Ard Biesheuvel wrote:
> On 27 June 2016 at 15:35, Christoffer Dall
> wrote:
> > On Mon, Jun 27, 2016 at 02:30:46PM +0200, Ard Biesheuvel wrote:
> >> On 27 June 2016 at 12:34, Christoffer Dall
> >> wrote:
> >> > On Mon, Jun 27, 2016 at 11:47:18AM +0200,
40 matches
Mail list logo
