Force the vfio-pci driver to only be bound explicitly via sysfs to avoid
conflics with other drivers in the event of a hotplug.
Signed-off-by: Kim Phillips kim.phill...@linaro.org
---
drivers/vfio/pci/vfio_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci.c
Set match_any_dev and sysfs_bind_only such that echoing a platform
device ID to the driver sysfs bind file will successfully match and bind
the device to the vfio-platform meta-driver in accordance to the
desired semantics for vfio drivers.
Signed-off-by: Kim Phillips kim.phill...@linaro.org
---
Platform drivers such as the vfio-platform meta- driver [1]
should be allowed to specify that they can bind to any device,
much like PCI drivers can with PCI_ANY_ID.
Currently, binding platform drivers to devices depends on:
- a string match in the device node's compatible entry (OF)
- a string
VFIO supports pass-through of devices to user space - for sake
of illustration, say a PCI e1000 device:
- the e1000 is first unbound from the PCI e1000 driver via sysfs
- the vfio-pci driver is told via new_id that it now handles e1000 devices
- the e1000 is explicitly bound to vfio-pci through
Hi Jan,
On Fri, Oct 11, 2013 at 12:12 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2013-10-02 20:47, Jan Kiszka wrote:
On 2013-09-30 11:08, Jan Kiszka wrote:
On 2013-09-26 17:04, Paolo Bonzini wrote:
Il 16/09/2013 10:11, Arthur Chunqi Li ha scritto:
This patch contains the following two
On Thu, Oct 10, 2013 at 02:27:05PM +, Hai Nguyen wrote:
Stefan Hajnoczi stefanha at gmail.com writes:
Thanks, Stefan!
In the network file system (NFS) approach you mentioned, I understand
that
the I/O requests will go directly from VM1 to VM2 via network before
reaching
Hi David,
I know it's been a while since you posted this patchset, but thought you
might appreciate the feedback anyway.
Some of my comments/suggestions relate to portability with MIPS32. I
don't object if you respond to those by just adding depends on 64BIT
so that I others can fix it up in
Do the necessary byteswap when host and guest have different
views of the universe. Actually, the only case we need to take
care of is when the guest is BE. All the other cases are naturally
handled.
Also be careful about endianness when the data is being memcopy-ed
from/to the run buffer.
This small patch series adds just enough kernel infrastructure and
fixes to allow a BE guest to use virtio-mmio on a LE host, provided
that the host actually supports such madness.
This has been tested on arm64, with some fixes to KVM and a set of
changes to kvmtool, both which I am posting
As virtio-mmio config registers are specified to be little-endian,
using readl() to read the magic value and then memcmp() to check it
fails on BE (as readl() has an implicit swab).
Fix it by encoding the magic value as an integer instead of a string.
Cc: Rusty Russell ru...@rustcorp.com.au
Cc:
This patch series adds some infrastructure to kvmtool to allow a BE
guest to use virtio-mmio on a LE host, provided that the architecture
actually supports such madness.
Not all the backend have been converted, only those I actually cared
about. Converting them is pretty easy though, and will be
Define a simple infrastructure to configure a virt_queue
depending on the guest endianness, as reported by the feature
flags. At this stage, the endianness is always the host's.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier
virtio_mmio defines the config space to be little-endian. This means
that a big-endian guest has to perform the access with byte-swapping
accessors.
The config space accessors are changed to take an access_size
parameter, allowing the low-level code to use the correct primitives.
Drivers and
In order for a guest to report its endianess, we introduce a pair of
per-ring flags: VIRTIO_RING_F_GUEST_{LE,BE}.
A host is allowed to advertise support for either or both endianess
for this ring. If it advertises none, it is assumed to be able to
handle the guest (best effort).
A guest is
Advertise bi-endianness support in the feature flags, and provide
byte-swapping of the config structure depending on the guest selection.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
tools/kvm/virtio/net.c | 17
Advertise bi-endianness support in the feature flags, and provide
byte-swapping of the config structure depending on the guest selection.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
tools/kvm/virtio/console.c | 12
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
tools/kvm/arm/include/arm-common/kvm-arch.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/kvm/arm/include/arm-common/kvm-arch.h
Wrap all accesses to virt_queue data structures shared between
host and guest with byte swapping helpers.
Should the architecture only support one endianness, these helpers
are reduced to the identity function.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Advertise bi-endianness support in the feature flags, and provide
byte-swapping of the config structure depending on the guest selection.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
tools/kvm/virtio/blk.c | 34
Advertise bi-endianness support in the feature flags, and provide
byte-swapping of the config structure depending on the guest selection.
Cc: Pekka Enberg penb...@kernel.org
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
tools/kvm/virtio/9p.c | 5 -
On Fri, Oct 11, 2013 at 03:36:30PM +0100, Marc Zyngier wrote:
Wrap all accesses to virt_queue data structures shared between
host and guest with byte swapping helpers.
Should the architecture only support one endianness, these helpers
are reduced to the identity function.
Cc: Pekka Enberg
On Fri, Oct 11, 2013 at 03:36:28PM +0100, Marc Zyngier wrote:
This patch series adds some infrastructure to kvmtool to allow a BE
guest to use virtio-mmio on a LE host, provided that the architecture
actually supports such madness.
Not all the backend have been converted, only those I
In vfio_iommu_type1.c there is a bug in vfio_dma_do_map, when checking
that pages are not already mapped. Since the check is being done in a
for loop nested within the main loop, breaking out of it does not create
the intended behavior. If the underlying IOMMU driver returns a non-NULL
value, this
On 11/10/13 15:50, Will Deacon wrote:
On Fri, Oct 11, 2013 at 03:36:30PM +0100, Marc Zyngier wrote:
Wrap all accesses to virt_queue data structures shared between
host and guest with byte swapping helpers.
Should the architecture only support one endianness, these helpers
are reduced to the
On Mon, Oct 07, 2013 at 07:06:06PM +0100, Will Deacon wrote:
On Mon, Sep 30, 2013 at 02:26:16PM +0100, Christoffer Dall wrote:
On 30 September 2013 05:38, Will Deacon will.dea...@arm.com wrote:
On Fri, Sep 27, 2013 at 06:38:52PM +0100, Jonathan Austin wrote:
The Cortex-A7 is very similar
On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
Force the vfio-pci driver to only be bound explicitly via sysfs to avoid
conflics with other drivers in the event of a hotplug.
Signed-off-by: Kim Phillips kim.phill...@linaro.org
---
drivers/vfio/pci/vfio_pci.c | 3 +++
1 file
On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
RCU (its too large). If the free memory watermarks are smaller than
n_max_mmu_pages for all guests, OOM is possible.
Ah, yes. I am not saying
Hi,
I have 2 VM's, one is running in NAT mode and the other in bridged mode.
VM1 IP is 192.168.122.3, and VM2 IP is on the public network, say 1.1.1.2.
If I am logged onto VM2 which has the public IP, I cannot access VM2,
since VM2 is on the private network. However from VM1 I can access
VM2. I
On Fri, 11 Oct 2013 15:43:40 -0500
Scott Wood scottw...@freescale.com wrote:
On Fri, 2013-10-11 at 01:27 -0500, Kim Phillips wrote:
Force the vfio-pci driver to only be bound explicitly via sysfs to avoid
conflics with other drivers in the event of a hotplug.
Signed-off-by: Kim Phillips
My bridge is setup as follows:
$sudo brctl show
bridge namebridge idSTP enabledinterfaces
br08000.d4ae52c951dfyesem1
vnet0
vnet4
virbr08000.5254000eed39yesvirbr0-nic
Implement reset of kernel watchdogs at pvclock read time. This avoids
adding special code to every watchdog.
This is possible for watchdogs which measure time based on sched_clock() or
ktime_get() variants.
Suggested by Don Zickus.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index:
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/kernel/hung_task.c
v2:
- do not create hung_task.h, move defines to sched.h (Don Zickus)
- switch patch order (Paolo)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote:
On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
RCU (its too large). If the free memory watermarks are smaller than
n_max_mmu_pages for
34 matches
Mail list logo
