Hi Dave,
On 01/03/2019 14:55, Dave Martin wrote:
> [FYI Peter, your views on the proposal outlined torward the end of the
> mail would be appreciated.]
>
> On Fri, Mar 01, 2019 at 01:28:19PM +, Julien Thierry wrote:
[...]
>> I might be over-thinking it, but if there is a way to move that
On 06/03/2019 23:46, Jacob Pan wrote:
> On Tue, 5 Mar 2019 15:03:41 +
> Jean-Philippe Brucker wrote:
>
>> On 18/02/2019 13:54, Eric Auger wrote:
>> [...]> +/**
>> > + * iommu_register_device_fault_handler() - Register a device fault
>> > handler
>> > + * @dev: the device
>> > + * @handler:
Pausing all vcpus when reconfiguring something at run time is a big
overhead. Use rwlock to allow vcpu not accessing ressources being
reconfigured to continue running.
Signed-off-by: Julien Thierry
---
include/kvm/brlock.h | 11 ---
include/kvm/kvm.h| 2 --
2 files changed, 13
Hi,
This series add support for guests writting to PCI BARs. Edk2 does this
and is not aware of the "linux,pci-probe-only" property in the chosen node.
- Patches 1 to 3 do miscelaneous fixes
- Patch 4 fixes the way we deal with BAR sizing
- Patches 5 to 8 fixes the allocation/assignment of PCI
Software can change the addresses of PCI BARs. In the case of virtio, the
BARs are associated with some IO ports or mmio regions. These are not
updated when the guest modifies PCI BARs, leading to some surprises.
Re-register the ports and mmio regions related to PCI BARs when they are
updated.
The kvm argument is not passed to br_read_lock/unlock, this works for
the barrier implementation because the argument is not used. This ever
breaks if another lock implementation is used.
Signed-off-by: Julien Thierry
---
ioport.c | 4 ++--
mmio.c | 4 ++--
2 files changed, 4 insertions(+), 4
PCI devices support BAR reassignment. Get rid of the no longer needed
linux property.
Signed-off-by: Julien Thierry
---
arm/fdt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arm/fdt.c b/arm/fdt.c
index 980015b..219248e 100644
--- a/arm/fdt.c
+++ b/arm/fdt.c
@@ -140,7 +140,6 @@ static int
A vcpu might reconfigure some ioports while other vcpus access another one.
Currently, edit to one port blocks all other ioport accesses.
Execute ioport callbacks outside of locking. protecting ioport data with
ref counting to prevent data being deleted while callback runs.
Since ioport struct
Provide a simple API with structure and function for reference counting.
This is inspired by the linux kref.
Signed-off-by: Julien Thierry
---
include/kvm/ref_cnt.h | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Currently, callbacks for memory BAR (BAR[1]) sits on the IO BAR, calling
the IO port emulation. This means that BAR[1] needs COMMAND_IO to be
enabled whenever COMMAND_MEMORY is enabled.
Refactor the code so both BARs are indenpendent. Also, unify ioport/mmio
callback arguments so that they all
A vcpu might reconfigure some memory mapped region while other vcpus
access another one. Currently, edit to one mmio region blocks all other
mmio accesses.
Execute mmio callbacks outside of locking, protecting mmio data with
ref counting to prevent data being deleted while callback runs.
The vesa framebuffer is only used by architectures that explicitly
require it (i.e. x86). Compile it out for architectures not using it, as
its current implementation might not work for them.
Signed-off-by: Julien Thierry
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The dynamic ioport allocation with IOPORT_EMPTY is currently only used
by PCI devices. Other devices use fixed ports for which they request
registration to the ioport API.
PCI ports need to be in the PCI IO space and there is no reason ioport
API should know a PCI port is being allocated and
From: Sami Mujawar
According to the 'PCI Local Bus Specification, Revision 3.0,
February 3, 2004, Section 6.2.5.1, Implementation Notes, page 227'
"Software saves the original value of the Base Address register,
writes 0 h to the register, then reads it back. Size
Linux has this convention that the lower 0x1000 bytes of the IO space
should not be used. (cf PCIBIOS_MIN_IO).
Just allocate those bytes to prevent future allocation assigning it to
devices.
Signed-off-by: Julien Thierry
---
arm/pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
When a guest can reassign BARs, kvmtool needs to maintain the vfio_region
consistent with their corresponding BARs. Take the new updated addresses
from the PCI header read back from the vfio driver.
Also, to modify the BARs, it is expected that guests will disable
IO/Memory response in the PCI
Current PCI IO region that is exposed through the DT contains ports that
are reserved by non-PCI devices.
Use the proper PCI IO start so that the region exposed through DT can
actually be used to reassign device BARs.
Signed-off-by: Julien Thierry
---
arm/include/arm-common/pci.h | 1 +
The PCI Local Bus Specification, Rev. 3.0,
Section 6.2.5.1. "Address Maps" states:
"Devices that map control functions into I/O Space must not consume more
than 256 bytes per I/O Base Address register."
Yet all the PCI devices allocate IO ports of IOPORT_SIZE (= 1024 bytes).
Fix this by having
On Thu, Mar 07, 2019 at 01:47:09PM +, Marc Zyngier wrote:
> Hi Dave,
>
> On 01/03/2019 14:55, Dave Martin wrote:
> > [FYI Peter, your views on the proposal outlined torward the end of the
> > mail would be appreciated.]
> >
> > On Fri, Mar 01, 2019 at 01:28:19PM +, Julien Thierry wrote:
> On 6 Mar 2019, at 11:40, Andre Przywara wrote:
>
> At the moment we initialise the target *mask* of a virtual IRQ to the
> VCPU it belongs to, even though this mask is only defined for GICv2 and
> quickly runs out of bits for many GICv3 guests.
Just for my education, “targets” seems defined
Hi Dave,
riginal Message-
> From: Dave Martin
> Sent: Tuesday, March 05, 2019 6:48 PM
> To: Zhang, Lei/張 雷
> Cc: kvmarm@lists.cs.columbia.edu; Peter Maydell
> ; Okamoto, Takayuki/岡本 高幸
> ; Christoffer Dall ; Ard
> Biesheuvel ; Marc Zyngier
> ; Catalin Marinas ; Will
> Deacon ; Julien Grall
21 matches
Mail list logo
