On 24/07/15 16:27, Pavel Fedin wrote:
>>> Ok, let's leave this API alone then for now...
>>> Will then be a concensus if i tweak the thing a little bit and we just
>>> enable KVM without both
> vGIC
>>> and vTimer ? It will be an emulator's problem how to handle them then.
>>
>> Well, let's see
In order to be able to feed physical interrupts to a guest, we need
to be able to establish the virtual-physical mapping between the two
worlds.
The mappings are kept in a set of RCU lists, indexed by virtual interrupts.
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/arm.c | 2 +
include/kv
So far, the only use of the HW interrupt facility is the timer,
implying that the active state is context-switched for each vcpu,
as the device is is shared across all vcpus.
This does not work for a device that has been assigned to a VM,
as the guest is entierely in control of that device (the HW
As we're about to cram more information in the vgic_lr structure
(HW interrupt number and additional state information), we switch
to a layout similar to the HW's:
- use bitfields to save space (we don't need more than 10 bits
to represent the irq numbers)
- source CPU and HW interrupt can share
To allow a HW interrupt to be injected into a guest, we lookup the
guest virtual interrupt in the irq_phys_map list, and if we have
a match, encode both interrupts in the LR.
We also mark the interrupt as "active" at the host distributor level.
On guest EOI on the virtual interrupt, the host inte
We only set the irq_queued flag for level interrupts, meaning
that "!vgic_irq_is_queued(vcpu, irq)" is a good enough predicate
for all interrupts.
This will allow us to inject edge HW interrupts, for which the
state ACTIVE+PENDING is not allowed.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc
As we're about to introduce some serious GIC-poking to the vgic code,
it is important to make sure that we're going to poke the part of
the GIC that belongs to the CPU we're about to run on (otherwise,
we'd end up with some unexpected interrupts firing)...
Introducing a non-preemptible section in
Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
field, we can encode that information into the list registers.
This patch provides implementations for both GICv2 and GICv3.
Signed-off-by: Marc Zyngier
---
include/linux/irqchip/arm-gic-v3.h | 3 +++
include/linux/irqchip/arm-
>From day 1, our timer code has been using a terrible hack: whenever
the guest is scheduled with a timer interrupt pending (i.e. the HW
timer has expired), we restore the timer state with the MASK bit set,
in order to avoid the physical interrupt to fire again. And again. And
again...
This is abso
In order to remove the crude hack where we sneak the masked bit
into the timer's control register, make use of the phys_irq_map
API control the active state of the interrupt.
This causes some limited changes to allow for potential error
propagation.
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/
Virtual interrupts mapped to a HW interrupt should only be triggered
from inside the kernel. Otherwise, you could end up confusing the
kernel (and the GIC's) state machine.
Rearrange the injection path so that kvm_vgic_inject_irq is
used for non-mapped interrupts, and kvm_vgic_inject_mapped_irq is
As we now inject the timer interrupt when we're about to enter
the guest, it makes a lot more sense to make sure this happens
before the vgic code queues the pending interrupts.
Otherwise, we get the interrupt on the following exit, which is
not great for latency (and leads to all kind of bizarre
In order to control the active state of an interrupt, introduce
a pair of accessors allowing the state to be set/queried.
This only affects the logical state, and the HW state will only be
applied at world-switch time.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
include/kvm/arm_
> > Ok, let's leave this API alone then for now...
> > Will then be a concensus if i tweak the thing a little bit and we just
> > enable KVM without both
vGIC
> > and vTimer ? It will be an emulator's problem how to handle them then.
>
> Well, let's see the patches first, and how invasive they
Hi all,
Linaro has developed the foundation for the new Android Emulator code
base based on a fairly recent upstream QEMU code base, when we
re-based the code, we updated the device model to be more virtio based
(for example the drives are now virtio block devices). The aim of this
is to minimise
Hi all,
Linaro has developed the foundation for the new Android Emulator code base
based on a fairly recent upstream QEMU code base, when we re-based the
code, we updated the device model to be more virtio based (for example the
drives are now virtio block devices). The aim of this is to minimise
In ARM/ARM64 MSI transactions goes through iommu/smmu.
This means there has to be an iommu mapping created for MSI addresses.
This patch adds a new ioctl "VFIO_DEVICE_PCI_MSI_VIRT_DOORBELL".
Userspace can call this ioctl to do following things:
1. Create a virtual doorbell mapping between
MSI IOV
In current VFIO MSI/MSI-X implementation, linux host kernel
allocates MSI/MSI-X vectors when userspace requests through vfio ioctls.
Vfio creates irqfd mappings to notify MSI/MSI-X interrupts
to the userspace when raised.
Guest OS will see emulated MSI/MSI-X controller and receives an interrupt
whe
In vfio we map and unmap various regions using "VFIO_IOMMU_MAP_DMA" and
"VFIO_IOMMU_UNMAP_DMA" ioctls from userspace.
Some device regions (like MSI in case of PCI), which we do not expose
to the userspace with mmap. These regions might require vfio driver
to create an iommu mapping, as their trans
19 matches
Mail list logo
