On Sep 19, 2014 2:33 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2014-09-17 at 09:07 -0700, Andy Lutomirski wrote:
It shouldn't. That being said, at some point this problem will need
solving on PPC, and this patch doesn't help much, other than adding
the virtio_ring
Cheers,
Ben.
--
Andy Lutomirski
AMA Capital Management, LLC
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Sep 19, 2014 9:40 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
I slept on it, and I think using the CPUID instruction alone would be
simple and efficient:
- We have a huge space for CPUID leaves
- CPUID also works for user-level
- It can
On Sep 19, 2014 9:53 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like
On Fri, Sep 19, 2014 at 10:36 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
We can always make cpuid on the leaf in question return all zeros if CPL 0
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote:
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would like to standardize on a very simple protocol by which a guest
OS can obtain an RNG seed early in boot.
The main design requirements
On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit nadav.a...@gmail.com wrote:
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
But if the goal is to provide something like getrandom(2) direct from
On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge
On Fri, Sep 19, 2014 at 4:35 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
probably need something new.
--Andy
-hpa
--
Andy Lutomirski
AMA Capital Management, LLC
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Thu, Sep 18, 2014 at 8:38 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/18/2014 07:40 AM, KY Srinivasan wrote:
The main questions are what MSR index to use and how to detect the
presence of the MSR. I've played
, 2014 10:18 AM
To: Nakajima, Jun; KY Srinivasan
Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels
Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux
Virtualization
Subject: Re: Standardizing an MSR or other hypercall to get an RNG seed?
Il 18/09
On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson ni...@microsoft.com wrote:
Defining a standard way of transferring random numbers between the host and
the guest is an excellent idea.
As the person who writes the RNG code in Windows, I have a few comments:
DETECTION:
It should be possible
On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Actually, that MSR address range has been reserved for that purpose, along
with:
- CPUID.EAX=1 - ECX bit 31 (always returns 0 on bare metal)
- CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID)
I don't know
On Thu, Sep 18, 2014 at 2:21 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski l...@amacapital.net wrote:
Might Intel be willing to extend that range to 0x4000 -
0x400f? And would Microsoft be okay with using this mechanism
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on
On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/18/2014 02:46 PM, David Hepkin wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that
each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f
CPUID range, and an OS has to do
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski l...@amacapital.net wrote:
So, as a concrete straw-man:
CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
0x4801) along with a signature value
On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski l...@amacapital.net wrote:
So, as a concrete straw-man:
CPUID leaf 0x4800 would return
On Sep 17, 2014 7:13 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 17, 2014 at 08:02:31AM -0400, Benjamin Herrenschmidt wrote:
On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote:
On non-PPC systems, virtio_pci should use the DMA API. This fixes
virtio_pci on Xen
On Wed, Sep 17, 2014 at 9:09 AM, Ira W. Snyder i...@ovro.caltech.edu wrote:
On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote:
On non-PPC systems, virtio_pci should use the DMA API. This fixes
virtio_pci on Xen. On PPC, using the DMA API would break things, so
we need
mechanism.
If we do the latter, I don't know what that mechanism would be.
NB: This thread will be cc'd to Microsoft and possibly Hyper-V people
shortly. I very much appreciate Jun Nakajima's help with this!
Thanks,
Andy
--
Andy Lutomirski
AMA Capital Management, LLC
kmemleak and
CONFIG_DMA_API_DEBUG. virtio-net warns (correctly) about DMA from
the stack in virtnet_set_rx_mode.
This explicitly supports !CONFIG_HAS_DMA. If vring is asked to use
the DMA API and CONFIG_HAS_DMA is not set, then vring will refuse to
create the virtqueue.
Signed-off-by: Andy
On non-PPC systems, virtio_pci should use the DMA API. This fixes
virtio_pci on Xen. On PPC, using the DMA API would break things, so
we need to preserve the old behavior.
The big comment in this patch explains the considerations in more
detail.
Signed-off-by: Andy Lutomirski l
is optional now. It would be nice to improve the
DMA API to the point that it could be used unconditionally, but s390
proves that we're not there yet.
- Includes patch 4, which fixes DMA debugging warnings from virtio_net.
Andy Lutomirski (3):
virtio_ring: Support DMA APIs if requested
Now that virtio supports real DMA, drivers should play by the rules.
For virtio_net, that means that DMA should be done to and from
dynamically-allocated memory, not the kernel stack.
This should have no effect on any performance-critical code paths.
Signed-off-by: Andy Lutomirski l
On Wed, Sep 10, 2014 at 8:36 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/04/2014 10:57 PM, Andy Lutomirski wrote:
There's a third option: try to make virtio-mmio work everywhere
(except s390), at least in the long run. This other benefits: it
makes minimal hypervisors simpler
On Sep 5, 2014 3:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 06:29, Rusty Russell ha scritto:
+ desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
+ if (!desc)
+ return NULL;
- return head;
+ for (i = 0; i total_sg; i++)
+
On Thu, Sep 4, 2014 at 7:31 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon
On Thu, Sep 4, 2014 at 7:32 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Sep 03, 2014 at 04:12:01PM +0930, Rusty Russell wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon
On Sep 2, 2014 11:53 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
There really are virtio devices that are pieces of silicon and not
figments of a hypervisor's imagination [1].
Hi Andy,
As you're discovering, there's a reason no one
On Wed, Sep 3, 2014 at 12:47 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 02:25, Benjamin Herrenschmidt ha scritto:
But there aren't any ACPI systems with both virtio-pci and IOMMUs,
right? So we could say that, henceforth, ACPI systems must declare
whether virtio-pci devices
On Sep 3, 2014 5:11 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47 +0200, Paolo Bonzini wrote:
IOMMU support for x86 is going to go in this week.
But won't that break virtio on x86 ? Or will virtio
On Wed, Sep 3, 2014 at 9:39 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Sep 03, 2014 at 08:07:15AM -0700, Andy Lutomirski wrote:
On Sep 3, 2014 5:11 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 03/09/2014 10:05, Benjamin Herrenschmidt ha scritto:
On Wed, 2014-09-03 at 09:47
On Tue, Sep 2, 2014 at 9:29 PM, Rusty Russell ru...@rustcorp.com.au wrote:
virtqueue_add() populates the virtqueue descriptor table from the sgs
given. If it uses an indirect descriptor table, then it puts a single
descriptor in the descriptor table pointing to the kmalloc'ed indirect
table
On Tue, Sep 2, 2014 at 5:43 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 17:32 -0700, Andy Lutomirski wrote:
I agree *except* that implementing it will be a real PITA and (I
think) can't be done without changing code in arch/. My patches plus
an ifdef powerpc
On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote:
On x86, at least, I doubt that we'll ever see a physically addressed
PCI virtio device for which ACPI advertises an IOMMU, since any sane
hypervisor
On Tue, Sep 2, 2014 at 2:10 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Sep 01, 2014 at 10:55:29PM -0700, Andy Lutomirski wrote:
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes
On Tue, Sep 2, 2014 at 3:10 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2014-09-02 at 14:37 -0700, Andy Lutomirski wrote:
Let's take a step back from from the implementation. What is a driver
for a virtio PCI device (i.e. a PCI device with vendor 0x1af4)
supposed to do
On Tue, Sep 2, 2014 at 4:20 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 16:11 -0700, Andy Lutomirski wrote:
I don't think so. I would argue that it's a straight-up bug for QEMU
to expose a physically-addressed virtio-pci device to the guest behind
an emulated
On Tue, Sep 2, 2014 at 5:25 PM, Benjamin Herrenschmidt b...@au1.ibm.com wrote:
On Tue, 2014-09-02 at 16:42 -0700, Andy Lutomirski wrote:
So here's an ugly proposal:
Step 1: Make virtio-pci use the DMA API only on x86. This will at
least fix Xen and people experimenting with virtio hardware
On Tue, Sep 2, 2014 at 9:29 PM, Rusty Russell ru...@rustcorp.com.au wrote:
This is the only driver which doesn't hand virtqueue_add_inbuf and
virtqueue_add_outbuf a well-formed, well-terminated sg. Fix it,
so we can make virtio_add_* simpler.
OK, I get it now: you're reinitializing the table
On Sep 1, 2014 12:00 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Aug 31, 2014 at 06:42:38PM -0700, Andy Lutomirski wrote:
On Sun, Aug 31, 2014 at 5:58 PM, Rusty Russell ru...@rustcorp.com.au
wrote:
Andy Lutomirski l...@amacapital.net writes:
The only unusual thing about
kmemleak and
CONFIG_DMA_API_DEBUG. virtio-net warns (correctly) about DMA from
the stack in virtnet_set_rx_mode.
This explicitly supports !CONFIG_HAS_DMA. If vring is asked to use
the DMA API and CONFIG_HAS_DMA is not set, then vring will refuse to
create the virtqueue.
Signed-off-by: Andy
can be removed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/virtio/virtio_pci.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index a1f299fa4626
, this will blow up.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/net/virtio_net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 59caa06f34a6..c90466a4fab0 100644
--- a/drivers/net/virtio_net.c
+++ b
patch 4, which fixes DMA debugging warnings from virtio_net.
Andy Lutomirski (4):
virtio_ring: Support DMA APIs if requested
virtio_pci: Use the DMA API for virtqueues
virtio_net: Don't set the end flag on reusable sg entries
virtio_net: Stop doing DMA from the stack
drivers/lguest
Now that virtio supports real DMA, drivers should play by the rules.
For virtio_net, that means that DMA should be done to and from
dynamically-allocated memory, not the kernel stack.
This should have no effect on any performance-critical code paths.
Signed-off-by: Andy Lutomirski l
On Mon, Sep 1, 2014 at 3:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2014-09-01 at 10:39 -0700, Andy Lutomirski wrote:
Changes from v1:
- Using the DMA API is optional now. It would be nice to improve the
DMA API to the point that it could be used unconditionally
On Sun, Aug 31, 2014 at 5:58 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
The only unusual thing about virtio's use of scatterlists is that
two of the APIs accept scatterlists that might not be terminated.
Using function pointers to handle
On Aug 28, 2014 7:17 AM, Gleb Natapov g...@kernel.org wrote:
On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR
On Thu, Aug 28, 2014 at 12:44 AM, Christian Borntraeger
borntrae...@de.ibm.com wrote:
On 27/08/14 23:50, Andy Lutomirski wrote:
This fixes virtio on Xen guests as well as on any other platform
that uses virtio_pci on which physical addresses don't match bus
addresses.
This can be tested
On Thu, Aug 28, 2014 at 11:29 AM, Christian Borntraeger
borntrae...@de.ibm.com wrote:
On 28/08/14 20:06, Andy Lutomirski wrote:
[...]
block seems to work, with net a simple ping works, iperf causes this:
I neither see the bug, nor can I reproduce it on x86_64 on KVM. I
doubt that dma vs
[removed virtio-dev -- I'm sick of bounces]
On Thu, Aug 28, 2014 at 11:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 20:29, Christian Borntraeger ha scritto:
block seems to work, with net a simple ping works, iperf causes this:
I neither see the bug, nor can I reproduce it
On Thu, Aug 28, 2014 at 12:18 PM, Christian Borntraeger
borntrae...@de.ibm.com wrote:
On 28/08/14 21:03, Andy Lutomirski wrote:
[removed virtio-dev -- I'm sick of bounces]
On Thu, Aug 28, 2014 at 11:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 20:29, Christian Borntraeger ha
to improve the
DMA API to the point that it could be used unconditionally, but s390
proves that we're not there yet.
- Includes patch 4, which fixes DMA debugging warnings from virtio_net.
Andy Lutomirski (5):
virtio_ring: Support DMA APIs if requested
virtio_pci: Use the DMA API
, this will blow up.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/net/virtio_net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 960a2172b07a..25703fd2df28 100644
--- a/drivers/net/virtio_net.c
+++ b
A virtqueue is a coherent DMA mapping. Use the DMA API for it.
This fixes virtio_pci on Xen.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/virtio/virtio_pci.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio
kmemleak and
CONFIG_DMA_API_DEBUG. virtio-net warns (correctly) about DMA from
the stack in virtnet_set_rx_mode.
This explicitly supports !CONFIG_HAS_DMA. If vring is asked to use
the DMA API and CONFIG_HAS_DMA is not set, then vring will refuse to
create the virtqueue.
Signed-off-by: Andy
On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/08/2014 18:22, Andy Lutomirski ha scritto:
Is there a non-cpuid interface between QEMU and KVM for this?
No.
Hmm. Then, assuming that someone manages to allocate a
cross-hypervisor MSR number for this, what am I
On Aug 27, 2014 4:30 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Andy Lutomirski l...@amacapital.net writes:
Currently, a lot of the virtio code assumes that bus (i.e. hypervisor)
addresses are the same as physical address. This is false on Xen, so
virtio is completely broken. I
On Aug 26, 2014 11:46 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Aug 26, 2014 at 10:16 PM, Andy Lutomirski l...@amacapital.net wrote:
There are two outstanding issues. virtio_net warns if DMA debugging
is on because it does DMA from the stack. (The warning is correct
On Wed, Aug 27, 2014 at 8:45 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Aug 27, 2014 at 08:11:15AM -0700, Andy Lutomirski wrote:
On Aug 26, 2014 11:46 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Aug 26, 2014 at 10:16 PM, Andy Lutomirski l...@amacapital.net
wrote
On Wed, Aug 27, 2014 at 9:13 AM, Christopher Covington
c...@codeaurora.org wrote:
On 08/27/2014 11:50 AM, Andy Lutomirski wrote:
On Wed, Aug 27, 2014 at 8:45 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Aug 27, 2014 at 08:11:15AM -0700, Andy Lutomirski wrote:
On Aug 26, 2014 11:46 PM
On Wed, Aug 27, 2014 at 10:32 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Tue, Aug 26, 2014 at 02:17:02PM -0700, Andy Lutomirski wrote:
A virtqueue is a coherent DMA mapping. Use the DMA API for it.
This fixes virtio_pci on Xen.
Signed-off-by: Andy Lutomirski l
On Wed, Aug 27, 2014 at 10:34 AM, Christopher Covington
c...@codeaurora.org wrote:
On 08/27/2014 12:19 PM, Andy Lutomirski wrote:
On Wed, Aug 27, 2014 at 9:13 AM, Christopher Covington
c...@codeaurora.org wrote:
Virtme looks interesting. If it's any use, here is my modest QEMU command line
On Wed, Aug 27, 2014 at 10:35 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Wed, Aug 27, 2014 at 09:29:36AM +0200, Christian Borntraeger wrote:
On 26/08/14 23:17, Andy Lutomirski wrote:
virtio_ring currently sends the device (usually a hypervisor)
physical addresses of its I/O
be nice to improve the
DMA API to the point that it could be used unconditionally, but s390
proves that we're not there yet.
- Includes patch 4, which fixes DMA debugging warnings from virtio_net.
Andy Lutomirski (4):
virtio_ring: Remove sg_next indirection
virtio_ring: Support DMA APIs
, but, because of the way that virtio_ring handles
multiple scatterlists at once, the count is only an upper bound if
there is more than one scatterlist. This is easily solved by
checking the sg pointer for NULL on each iteration.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers
kmemleak and
CONFIG_DMA_API_DEBUG. virtio-net warns (correctly) about DMA from
the stack in virtnet_set_rx_mode.
This explicitly supports !CONFIG_HAS_DMA. If vring is asked to use
the DMA API and CONFIG_HAS_DMA is not set, then vring will refuse to
create the virtqueue.
Signed-off-by: Andy
Now that virtio supports real DMA, drivers should play by the rules.
For virtio_net, that means that DMA should be done to and from
dynamically-allocated memory, not the kernel stack.
This should have no effect on any performance-critical code paths.
Signed-off-by: Andy Lutomirski l
A virtqueue is a coherent DMA mapping. Use the DMA API for it.
This fixes virtio_pci on Xen.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/virtio/virtio_pci.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio
are cc'd -- I don't know what to do about it.)
Andy Lutomirski (3):
virtio_ring: Remove sg_next indirection
virtio_ring: Use DMA APIs
virtio_pci: Use the DMA API for virtqueues
drivers/virtio/Kconfig | 1 +
drivers/virtio/virtio_pci.c | 25 ++--
drivers/virtio/virtio_ring.c
A virtqueue is a coherent DMA mapping. Use the DMA API for it.
This fixes virtio_pci on Xen.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/virtio/virtio_pci.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/virtio
through a PCI IOMMU, which is presumably not the
case for virtio.
Cc: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/virtio/Kconfig | 1 +
drivers/virtio/virtio_ring.c | 116 +++
2 files changed
, but, because of the way that virtio_ring handles
multiple scatterlists at once, the count is only an upper bound if
there is more than one scatterlist. This is easily solved by
checking the sg pointer for NULL on each iteration.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR that everyone involved can agree on and, rather
than relying on a cpuid bit, just have the guest probe for the MSR.
This leads to a few
address is enough to call kfree, and I don't think that the DMA API
provides a reverse mapping like that.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https
On Mon, Aug 25, 2014 at 11:54 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Aug 25, 2014 at 10:18:46AM -0700, Andy Lutomirski wrote:
Currently, a lot of the virtio code assumes that bus (i.e. hypervisor)
addresses are the same as physical address. This is false on Xen, so
I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm
with these options:
-chardev null,id=hvc0,signal=off
-device virtio-serial-pci
-device virtconsole,chardev=hvc0,name=virtme_console
-append console=hvc0 console=ttyS0
-nographic
(There are more, but these are the interesting
On Mon, Mar 31, 2014 at 3:31 PM, Andy Lutomirski l...@amacapital.net wrote:
I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm
with these options:
-chardev null,id=hvc0,signal=off
-device virtio-serial-pci
-device virtconsole,chardev=hvc0,name=virtme_console
-append console
to handle performance regression reports :)
[1] https://gitorious.org/linux-test-utils/linux-clock-tests
Changes from v1:
- Improve changelog message for x86-64/xen: Enable the vvar mapping
- Fix 32-bit build.
- Add patch 6.
Andy Lutomirski (6):
x86-64: Pad vDSO to a page boundary
x86-64
The kernel's loader doesn't seem to care, but gold complains.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Arkadiusz Miskiewicz a.miskiew...@gmail.com
---
arch/x86/kernel/vmlinux.lds.S | 36 ++--
1 files changed, 18 insertions(+), 18 deletions
of doing it.
This produces an apparently valid kernel image and passes my vdso
tests on both GNU ld version 2.21.51.0.6-2.fc15 20110118 and GNU
gold (version 2.21.51.0.6-2.fc15 20110118) 1.10 as distributed by
Fedora 15.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Arkadiusz Miskiewicz
Vsyscall emulation is slow, so make it easy to track down.
Signed-off-by: Andy Lutomirski l...@mit.edu
---
arch/x86/kernel/vsyscall_64.c|6 ++
arch/x86/kernel/vsyscall_trace.h | 29 +
2 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644
, pg_owner=10
(XEN) mm.c:5049:d10 ptwr_emulate: could not get_page_from_l1e()
[0.00] BUG: unable to handle kernel NULL pointer dereference at (null)
[0.00] IP: [8103a930] xen_set_pte+0x20/0xe0
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Konrad Rzeszutek Wilk
a little ugly because
ptrace.h can't include paravirt.h.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/include/asm/desc.h |4 ++--
arch/x86/include/asm/paravirt_types.h |6 ++
arch/x86/include/asm/ptrace.h
This avoids an information leak to userspace.
Signed-off-by: Andy Lutomirski l...@mit.edu
---
arch/x86/vdso/vdso.S |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S
index 1b979c1..01f5e3b 100644
--- a/arch/x86/vdso/vdso.S
+++ b
a usable Xen setup.
Also, I'd appreciate a review of patches 4 and 5 from some Xen/paravirt
people.
[1] https://gitorious.org/linux-test-utils/linux-clock-tests
Andy Lutomirski (5):
x86-64: Pad vDSO to a page boundary
x86-64: Move the user vsyscall segment out of the data segment.
x86-64
of doing it.
This produces an apparently valid kernel image and passes my vdso
tests on both GNU ld version 2.21.51.0.6-2.fc15 20110118 and GNU
gold (version 2.21.51.0.6-2.fc15 20110118) 1.10 as distributed by
Fedora 15.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Arkadiusz Miskiewicz
Xen needs special treatment for fixmaps.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/mmu.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f987bde
a little ugly because
ptrace.h can't include paravirt.h.
Signed-off-by: Andy Lutomirski l...@mit.edu
Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/include/asm/desc.h |4 ++--
arch/x86/include/asm/paravirt_types.h |6 ++
arch/x86/include/asm/ptrace.h
201 - 295 of 295 matches
Mail list logo
