On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
On 14 May 2015 at 11:31, Andrew Jones drjo...@redhat.com wrote:
Forgot to (4): switch from setting userspace's mapping to
device memory to normal, non-cacheable. Using device memory
caused a problem that Alex Graf found, and
On Thu, May 14, 2015 at 01:38:38PM +0200, Paolo Bonzini wrote:
On 14/05/2015 13:36, Christoffer Dall wrote:
(It's probably worth looking at the documentation in the first hunk
too,
under the commit message.)
Why is this a hack/unintuitive? Is the semantics of the
On 05/14/15 15:00, Andrew Jones wrote:
On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
On 14 May 2015 at 13:28, Paolo Bonzini pbonz...@redhat.com wrote:
Well, PCI BARs are generally MMIO resources, and hence should not be cached.
As an optimization, OS drivers can mark them as
On Fri, Mar 27, 2015 at 01:09:25PM +, Marc Zyngier wrote:
So far, we configured the world-switch by having a small array
of pointers to the save and restore functions, depending on the
GIC used on the platform.
Loading these values each time is a bit silly (they never change),
and it
On 14 May 2015 at 13:28, Paolo Bonzini pbonz...@redhat.com wrote:
Well, PCI BARs are generally MMIO resources, and hence should not be cached.
As an optimization, OS drivers can mark them as cacheable or
write-combining or something like that, but in general it's a safe
default to leave them
On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:00, Christoffer Dall wrote:
So, getting back to my original question. Is the point then that UEFI
must assume (from ACPI/DT) the cache-coherency properties of the PCI
controller which exists in hardware on
On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:24, Christoffer Dall wrote:
On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:00, Christoffer Dall wrote:
So, getting back to my original question. Is the point then that
On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
On 14 May 2015 at 13:28, Paolo Bonzini pbonz...@redhat.com wrote:
Well, PCI BARs are generally MMIO resources, and hence should not be cached.
As an optimization, OS drivers can mark them as cacheable or
write-combining or
On 14 May 2015 at 14:03, Andrew Jones drjo...@redhat.com wrote:
On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
On 14 May 2015 at 11:31, Andrew Jones drjo...@redhat.com wrote:
Forgot to (4): switch from setting userspace's mapping to
device memory to normal, non-cacheable.
On Thu, May 14, 2015 at 01:05:09PM +0200, Christoffer Dall wrote:
On Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
Provide a method to change normal, cacheable memory to non-cacheable.
KVM will make use of this to keep emulated device memory regions
coherent with the guest.
On 05/14/15 14:34, Christoffer Dall wrote:
On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:24, Christoffer Dall wrote:
On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:00, Christoffer Dall wrote:
So, getting back to my
On 14/05/2015 14:00, Christoffer Dall wrote:
So, getting back to my original question. Is the point then that UEFI
must assume (from ACPI/DT) the cache-coherency properties of the PCI
controller which exists in hardware on the system you're running on,
even for the virtual PCI bus because
On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
On 05/14/15 15:00, Andrew Jones wrote:
On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
On 14 May 2015 at 13:28, Paolo Bonzini pbonz...@redhat.com wrote:
Well, PCI BARs are generally MMIO resources, and hence should
On Thu, 2015-05-14 at 10:25 +0200, Eric Auger wrote:
Hi Alex,
On 05/13/2015 08:32 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
vfio_platform_common now stores a lists of available reset functions.
Two functions are exposed to register/unregister a reset
On 05/14/15 12:30, Christoffer Dall wrote:
On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
needed by ARM. This flag informs KVM that the given memory region
is typically mapped by the guest as non-cacheable. KVM for
On Thu, May 14, 2015 at 01:09:34PM +0200, Laszlo Ersek wrote:
On 05/14/15 12:30, Christoffer Dall wrote:
On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
needed by ARM. This flag informs KVM that the given memory
On 14/05/2015 13:29, Christoffer Dall wrote:
(It's probably worth looking at the documentation in the first hunk too,
under the commit message.)
Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
not simply that MMIO regions are coherent?
Only until device assignment
On Thu, May 14, 2015 at 01:31:03PM +0200, Paolo Bonzini wrote:
On 14/05/2015 13:29, Christoffer Dall wrote:
(It's probably worth looking at the documentation in the first hunk too,
under the commit message.)
Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
On 14/05/2015 13:36, Christoffer Dall wrote:
(It's probably worth looking at the documentation in the first hunk too,
under the commit message.)
Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
not simply that MMIO regions are coherent?
Only until
On 05/13/2015 08:32 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
It is needed to introduce a new callback enabling to retrieve the
struct device* from the vfio_platform_device. Implementation depends
on the underlying device, platform or amba. This will be
Alex,
On 05/13/2015 08:33 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
This patch introduces a module that registers and implements a basic
reset function for the Calxeda xgmac device. This latter basically disables
interrupts and stops DMA transfers.
The
Hi Alex,
On 05/13/2015 08:32 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
vfio_platform_common now stores a lists of available reset functions.
Two functions are exposed to register/unregister a reset function. A
reset function is paired with a compat string.
On 05/13/2015 08:32 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
A new reset callback is introduced. If this callback is populated,
the reset is invoked on device release or upon userspace ioctl. The
modality is exposed on VFIO_DEVICE_GET_INFO.
On 05/13/2015 08:33 PM, Alex Williamson wrote:
On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
Add the reset function lookup according to the device compat
string. This lookup is added at different places:
- on VFIO_DEVICE_GET_INFO
- on VFIO_DEVICE_RESET
- on device release
A
On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
needed by ARM. This flag informs KVM that the given memory region
is typically mapped by the guest as non-cacheable. KVM for ARM
then ensures that that memory is indeed
On 14 May 2015 at 11:31, Andrew Jones drjo...@redhat.com wrote:
Forgot to (4): switch from setting userspace's mapping to
device memory to normal, non-cacheable. Using device memory
caused a problem that Alex Graf found, and Peter Maydell suggested
using normal, non-cacheable instead.
Did you
On Wed, May 13, 2015 at 01:31:54PM +0200, Andrew Jones wrote:
When S1 and S2 memory attributes combine wrt to caching policy,
non-cacheable types take precedence. If a guest maps a region as
device memory, which KVM userspace is using to emulate the device
using normal, cacheable memory, then
On Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
Provide a method to change normal, cacheable memory to non-cacheable.
KVM will make use of this to keep emulated device memory regions
coherent with the guest.
Signed-off-by: Andrew Jones drjo...@redhat.com
Reviewed-by:
28 matches
Mail list logo
