platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
-Original Message-
From: Wu, Feng
Sent: Friday, July 10, 2015 12:13 PM
To: Alex Williamson
Cc: kvm@vger.kernel.org; pbonz...@redhat.com; j...@8bytes.org;
avi.kiv...@gmail.com; eric.au...@linaro.org; Wu, Feng
Subject: RE: [RFC v1 5/5] Call irqbypass update routine when updating
On 10/07/15 09:17, Jiang Liu wrote:
On 2015/7/10 15:52, Marc Zyngier wrote:
On 09/07/15 22:33, Thomas Gleixner wrote:
On Thu, 9 Jul 2015, Marc Zyngier wrote:
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When
On 09/07/15 22:33, Thomas Gleixner wrote:
On Thu, 9 Jul 2015, Marc Zyngier wrote:
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When used as a secondary interrupt controller, it uses handler_data
instead. As
On 2015/7/10 15:52, Marc Zyngier wrote:
On 09/07/15 22:33, Thomas Gleixner wrote:
On Thu, 9 Jul 2015, Marc Zyngier wrote:
When used as a primary interrupt controller, the GIC driver uses
irq_data-chip_data to extract controller-specific information.
When used as a secondary interrupt
Thanks for the point Krzysztof.
Acked-by: Baptiste Reynal b.rey...@virtualopensystems.com
On Fri, Jul 10, 2015 at 8:37 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof
We can disable CD unconditionally when there is no assigned device.
KVM now forces guest PAT to all-writeback in that case, so it makes
sense to also force CR0.CD=0.
When there are assigned devices, emulate cache-disabled operation
through the page tables. This behavior is consistent with VMX,
On 09/07/2015 21:49, Jan Kiszka wrote:
CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
- CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+ CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_TRAP_FLAG |
CPU_BASED_MONITOR_EXITING |
Overlong line.
On 08/07/2015 19:54, Marc Zyngier wrote:
Alternatively, I could move it to arch/arm64/include/asm (renamed to
kvm_vhe_macros.h?), which would solve this issue. I just gave it a go,
and that seems sensible enough.
Yes, that would do. Alternatively:
* create kvm_hyp_macros.h and put more
On 10/07/2015 10:28, Wu, Feng wrote:
Yes, you are right. All we need is the producer information which has been
passed in the register routine. And we can easily make this update logic
inside the consumer. Thanks for your comments!
BTW, Paolo Alex, in VFIO framework, how can we know a
On Fri, Jul 10, 2015 at 02:01:33PM +0200, Paolo Bonzini wrote:
We can disable CD unconditionally when there is no assigned device.
KVM now forces guest PAT to all-writeback in that case, so it makes
sense to also force CR0.CD=0.
When there are assigned devices, emulate cache-disabled
Laszlo Ersek ler...@redhat.com writes:
On 07/10/15 16:59, Paolo Bonzini wrote:
On 10/07/2015 16:57, Laszlo Ersek wrote:
... In any case, please understand that I'm not campaigning for this
warning :) IIRC the warning was your (very welcome!) idea after I
reported the problem; I'm just
On 09/07/2015 20:57, Laszlo Ersek wrote:
Without EPT, you don't
hit the processor limitation with your setup, but the user should
nevertheless
still be notified.
I disagree.
FWIW, I also disagree (and it looks like Bandan disagrees with himself
now :)).
In fact, I think shadow paging
On 07/10/15 16:13, Paolo Bonzini wrote:
On 09/07/2015 20:57, Laszlo Ersek wrote:
Without EPT, you don't
hit the processor limitation with your setup, but the user should
nevertheless
still be notified.
I disagree.
FWIW, I also disagree (and it looks like Bandan disagrees with
On 07/10/15 16:59, Paolo Bonzini wrote:
On 10/07/2015 16:57, Laszlo Ersek wrote:
... In any case, please understand that I'm not campaigning for this
warning :) IIRC the warning was your (very welcome!) idea after I
reported the problem; I'm just trying to ensure that the warning match
On 10/07/2015 03:19, Xiao Guangrong wrote:
yes, this is correct. QEMU still does not have support for disabling
quirks, so gCR0.CD is currently hidden on SVM. I would like to
include this series in 4.2, while for 4.3 I will disable the quirk above
altogether (it is superseded by the way
On Fri, 2015-07-10 at 14:47 +0200, Paolo Bonzini wrote:
On 10/07/2015 10:28, Wu, Feng wrote:
Yes, you are right. All we need is the producer information which has been
passed in the register routine. And we can easily make this update logic
inside the consumer. Thanks for your
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
Currently we initialize all the possible GIC frame addresses in one
function, without looking at the specific GIC model we instantiate
for the guest.
As this gets confusing when adding another VGIC model later, lets
move these initializations into the respective model's init functions.
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.
Introduce the skeleton with function stubs to be filled later.
Introduce the basic ITS data structure and initialize it, but don't
return any success yet, as we
Currently we track which IRQ has been mapped to which VGIC list
register and also have to synchronize both. We used to do this
to hold some extra state (for instance the active bit).
It turns out that this extra state in the LRs is no longer needed and
this extra tracking causes some pain later.
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
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
Hi,
this respin tries to address all comments I got so far from the list.
Thanks to Eric, Pavel and Christoffer for the review!
The major change in this series is the reworked locking. The current
implementation is now much more fine grained and avoids any calls to
functions that could possibly
The GICv3 Interrupt Translation Service (ITS) uses tables in memory
to allow a sophisticated interrupt routing. It features device tables,
an interrupt table per device and a table connecting collections to
actual CPUs (aka. redistributors in the GICv3 lingo).
Since the interrupt numbers for the
The ARM GICv3 ITS controller requires a separate register frame to
cover ITS specific registers. Add a new VGIC address type and store
the address in a field in the vgic_dist structure.
Provide a function to check whether userland has provided the address,
so ITS functionality can be guarded by
The LPI configuration and pending tables of the GICv3 LPIs are held
in tables in (guest) memory. To achieve reasonable performance, we
cache this data in our own data structures, so we need to sync those
two views from time to time. This behaviour is well described in the
GICv3 spec and is also
Add emulation for some basic MMIO registers used in the ITS emulation.
This includes:
- GITS_{CTLR,TYPER,IIDR}
- ID registers
- GITS_{CBASER,CREADR,CWRITER}
those implement the ITS command buffer handling
Most of the handlers are pretty straight forward, but CWRITER goes
some extra miles to
Currently we destroy the VGIC emulation in one function that cares for
all emulated models. To be on par with init_model (which is model
specific), lets introduce a per-emulation-model destroy method, too.
Use it for a tiny GICv3 specific code already, later it will be handy
for the ITS emulation.
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
As the actual LPI number in a guest can be quite high, but is mostly
assigned using a very sparse allocation scheme, bitmaps and arrays
for storing the virtual interrupt status are a waste of memory.
We use our equivalent of the Interrupt Translation Table Entry
(ITTE) to hold this extra status
When userland wants to inject a MSI into the guest, we have to use
our data structures to find the LPI number and the VCPU to receive
the interrupt.
Use the wrapper functions to iterate the linked lists and find the
proper Interrupt Translation Table Entry. Then set the pending bit
in this ITTE to
If userspace has provided a base address for the ITS register frame,
we enable the bits that advertise LPIs in the GICv3.
When the guest has enabled LPIs and the ITS, we enable the emulation
part by initializing the ITS data structures and trapping on ITS
register frame accesses by the guest.
Also
When a physical I/O device is assigned to a virtual machine through
facilities like VFIO and KVM, the interrupt for the device generally
bounces through the host system before being injected into the VM.
However, hardware technologies exist that often allow the host to be
bypassed for some of
Add support to convert unit tests to standalone scripts that
can be run outside the framework. This is almost an RFC, but
it doesn't impact the current framework (except for 'make install',
but was that ever used?). The scripting is ugly, but I see value
in having easily distributable unit tests.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
run_tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/run_tests.sh b/run_tests.sh
index e48f1db049f81..6f00aa495744c 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -120,7 +120,7 @@ specify the appropriate qemu binary
Signed-off-by: Andrew Jones drjo...@redhat.com
---
README | 10 ++
1 file changed, 10 insertions(+)
diff --git a/README b/README
index e9869d12bfa20..8bc966bdf1284 100644
--- a/README
+++ b/README
@@ -16,6 +16,16 @@ To select a specific qemu binary, specify the QEMU=path
environment
This is a super ugly bash script, wrapped around a couple ugly
bash scripts, and it generates an ugly bash script. But, it gets
the job done. What's the job? Take a unit test and generate a
standalone script that can be run on any appropriate system with
an appropriate qemu. This makes
On 07/10/2015 06:47 PM, Paolo Bonzini wrote:
On 10/07/2015 03:19, Xiao Guangrong wrote:
yes, this is correct. QEMU still does not have support for disabling
quirks, so gCR0.CD is currently hidden on SVM. I would like to
include this series in 4.2, while for 4.3 I will disable the quirk
On 07/10/2015 08:01 PM, Paolo Bonzini wrote:
We can disable CD unconditionally when there is no assigned device.
KVM now forces guest PAT to all-writeback in that case, so it makes
sense to also force CR0.CD=0.
When there are assigned devices, emulate cache-disabled operation
through the page
On Friday 10 July 2015 13:28:26 Paolo Bonzini wrote:
On 09/07/2015 21:49, Jan Kiszka wrote:
CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
-CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+CPU_BASED_USE_IO_BITMAPS |
We'll use a variable from config.mak in a later patch. Try not to break
users that have gotten used to doing cd x86; ./run test.flat by also
looking in the parent directory. While at it, add this parent directory
check to arm too.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arm/run | 8
Add an option that allows us to just get the qemu command line
for each test. Running ./run_tests.sh -d will result in each
test saying it passed, and test.log will contain a list of each
qemu command line that would have been executed, had it not been
a dry-run.
Signed-off-by: Andrew Jones
Signed-off-by: Andrew Jones drjo...@redhat.com
---
run_tests.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/run_tests.sh b/run_tests.sh
index 4246f1b60a733..4a9c54b0817cd 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -110,13 +110,14 @@ function usage()
{
cat
make install wasn't very useful without also installing scripts for
the qemu command lines. I suspect 'make install' was never used.
Installing standalone tests could be useful though, so let's do
that instead.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
Makefile | 6
Prepares for the mkstandalone script coming in a later patch.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arm/unittests.cfg | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index 32fb4bb6c146b..8fae8a714a83b 100644
---
Quotes, bash, and bash generation from bash are painful enough
without having to handle both single and double quotes. Let's
just handle double. This prepares for the mkstandalone script
coming in a later patch.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arm/unittests.cfg | 8
On 10/07/2015 16:57, Laszlo Ersek wrote:
... In any case, please understand that I'm not campaigning for this
warning :) IIRC the warning was your (very welcome!) idea after I
reported the problem; I'm just trying to ensure that the warning match
the exact issue I encountered.
On 10/07/2015 19:52, Alex Williamson wrote:
Perhaps if a second consumer comes along that would be justification for
tying it elsewhere in the build system. ARM will obviously need to do
similar. Are there better options?
Also, there's no maintainer for the top level virt/ directory.
On 09/07/15 09:22, Eric Auger wrote:
On ARM, the MSI msg (address and data) comes along with
out-of-band device ID information. The device ID encodes the
device that writes the MSI msg. Let's convey the device id in
kvm_irq_routing_msi and use a new routing entry type to
indicate the devid is
On Sat, Dec 1, 2012 at 5:33 PM, Asias He as...@redhat.com wrote:
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request to bio and use submit_bio() to submit I/O directly.
So this version any supports
Hi Eric,
On 09/07/15 09:22, Eric Auger wrote:
This patch adds compilation and link against irqchip.
On ARM, irqchip routing is not really useful since there is
a single irqchip. However main motivation behind using irqchip
code is to enable MSI routing code. With the support of in-kernel
On 09/07/15 09:22, Eric Auger wrote:
on ARM, a devid field is populated in kvm_msi struct in case the
flag is set to KVM_MSI_VALID_DEVID. Let's populate the corresponding
kvm_kernel_irq_routing_entry devid field and set the msi type to
KVM_IRQ_ROUTING_EXTENDED_MSI.
Signed-off-by: Eric Auger
On 09/07/15 09:22, Eric Auger wrote:
Up to now, only irqchip routing entries could be set. This patch
adds the capability to insert MSI routing entries, with or without
device id. Although standard MSI entries can be set, their
injection still is not supported. For ARM64, let's also increase
On 09/07/15 09:22, Eric Auger wrote:
If the ITS modality is not available, let's simply support MSI
injection by transforming the MSI.data into an SPI ID.
This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
v1 - v2:
-
55 matches
Mail list logo
