Hi Michael,
On Mon, Sep 15, 2014 at 1:32 AM, Michael S. Tsirkin wrote:
> On Sun, Sep 14, 2014 at 08:23:26PM -0700, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> If MSI-X initialization fails after setting msix_enabled = 1, then
>> the device is left in an inco
Hi Michael,
On Mon, Sep 15, 2014 at 1:32 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Sep 14, 2014 at 08:23:26PM -0700, Anthony Liguori wrote:
From: Anthony Liguori aligu...@amazon.com
If MSI-X initialization fails after setting msix_enabled = 1, then
the device is left
From: Anthony Liguori
Commit 5dc03639 switched blkback to also add m2p override entries
when mapping grant pages but history seems to have forgotten why
this is useful if it ever was.
The blkback driver does not need m2p override entries to exist
and there is significant overhead due
From: Anthony Liguori aligu...@amazon.com
Commit 5dc03639 switched blkback to also add m2p override entries
when mapping grant pages but history seems to have forgotten why
this is useful if it ever was.
The blkback driver does not need m2p override entries to exist
and there is significant
Ian Campbell writes:
> On Tue, 2013-11-05 at 12:53 -0800, Anthony Liguori wrote:
>> >> Yes, you are completely right, then I have to figure out why blkback
>> >> works fine with this patch applied (or at least it seems to work fine).
>> >
>> > blk
Ian Campbell ian.campb...@citrix.com writes:
On Tue, 2013-11-05 at 12:53 -0800, Anthony Liguori wrote:
Yes, you are completely right, then I have to figure out why blkback
works fine with this patch applied (or at least it seems to work fine).
blkback also works for me when testing
On Tue, Nov 5, 2013 at 1:16 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Nov 05, 2013 at 12:53:17PM -0800, Anthony Liguori wrote:
>> Matt Wilson writes:
>>
>> > On Tue, Nov 05, 2013 at 05:03:58PM +0100, Roger Pau Monné wrote:
>> >> On 05/11/13 16:08, Ian Campbe
roduced in:
commit 5dc03639cc903f887931831d69895facb5260f4b
Author: Konrad Rzeszutek Wilk
Date: Tue Mar 1 16:46:45 2011 -0500
xen/blkback: Utilize the M2P override mechanism for GNTMAP_host_map
Purely as an optimization. In practice though due to lock contention it
slows things down.
I thi
.
I think an alternative would be to use a read/write lock instead of just
a spinlock since it's the read path that is the most hot.
I haven't tested that yet though.
Regards,
Anthony Liguori
Adding Anthony to the thread.
--msw
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Nov 5, 2013 at 1:16 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Tue, Nov 05, 2013 at 12:53:17PM -0800, Anthony Liguori wrote:
Matt Wilson m...@linux.com writes:
On Tue, Nov 05, 2013 at 05:03:58PM +0100, Roger Pau Monné wrote:
On 05/11/13 16:08, Ian Campbell wrote
pened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at htt
).
That all happened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
re
> users than it would clarify.
I'll bring you a nice bottle of scotch at the next KVM Forum if you can
find me one user that can accurately describe what steal time is.
The semantics are so incredibly subtle that I have a hard time believing
anyone actually understands what it means today.
incredibly subtle that I have a hard time believing
anyone actually understands what it means today.
Regards,
Anthony Liguori
---
Michael Wolf (5):
Alter the amount of steal time reported by the guest.
Expand the steal time msr to also contain the consigned time.
Add
. If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
. If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
ports too. But extending the
PCI config space (especially dealing with capability allocation) is
pretty gnarly and there isn't an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device registers outside the platform devices (that
an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device registers outside the platform devices (that have no BARs).
Regards,
Anthony Liguori
5) Changes to the ring layout and other such things are deferred to a
future virtio
Rusty Russell writes:
> Anthony Liguori writes:
>> Rusty Russell writes:
>>
>>> "Michael S. Tsirkin" writes:
>>>
>>>> Thinking about Sasha's patches, we can reduce ring usage
>>>> for virtio net small packets dramatically i
ture bit, the vnet
header can be in the same element as the data but not allow the header
to be spread across multiple elements.
Regards,
Anthony Liguori
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 8d5bddb..930a4ea 100644
> --- a/drivers/virti
of the existing implementations.
Users use implementations, not specifications. The specification really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the header
to be spread across multiple elements.
Regards,
Anthony Liguori
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 8d5bddb..930a4ea 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -5,6 +5,15 @@ config VIRTIO
bus
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets dramatically if we put
er being unallocated
> time). The guest could then present it any way it wanted to.
What I had previously suggested what splitting entitlement loss out of
steal time and reporting it as a separate metric (but not reporting a
fixed notion of entitlement).
You're missing the entitlement loss bit
does) is wrong.
Regards,
Anthony Liguori
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
the guest. So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
Alan
--
To unsubscribe from this list: send
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti writes:
>> >>
>> >>
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >>
>> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wro
nic-device" should cover other OSes is also
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic?
>
> Is the mechanism general enough for supporting new events, etc.
Hi,
I think thi
. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
Regards,
Anthony Liguori
Well, we have more than a single serial port, even when leaving
virtio-serial aside
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012
Sasha Levin writes:
> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>>> We can know the guest is panicked when the guest runs on xen.
>>>> But we do not hav
Sasha Levin writes:
> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>>> Sasha Levin writes:
>>>
>>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>>> +#define KVM_PV_PORT (0x5
Sasha Levin writes:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>> +#define KVM_PV_PORT (0x505UL)
>>>> +
>>>> #ifdef __KERNEL__
>>
for something like this (as long as
you check to make sure that you really are under KVM).
Regards,
Anthony Liguori
> --
> 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://v
dog/, and gain a more complete solution to
> detecting hangs inside the guest.
The purpose of virtio is not to reinvent every possible type of device.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
Watchdogs are
.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
Watchdogs are not performance sensitive so there's no point in using
virtio.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
).
Regards,
Anthony Liguori
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 09:22 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 09:12 AM, Wen Congyang wrote:
+#define KVM_PV_PORT (0x505UL)
+
#ifdef __KERNEL__
#include asm/processor.h
@@ -221,6 +223,11
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 10:19 PM, Sasha Levin wrote:
On 07/22/2012 09:22 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 09:12 AM, Wen Congyang wrote:
+#define KVM_PV_PORT (0x505UL)
+
#ifdef __KERNEL__
#include
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 09:14 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 10:44 AM, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another
"Michael S. Tsirkin" writes:
> On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
>> Of course, the million dollar question is why would using AIO in the
>> kernel be faster than using AIO in userspace?
>
> Actually for me a more important
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
Of course, the million dollar question is why would using AIO in the
kernel be faster than using AIO in userspace?
Actually for me a more important question is how does it compare
to me. I'm sure there's sufficient
incentive to patch Hyper-V for this at Microsoft...
Regards,
Anthony Liguori
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
status = ret < 0 ? VIRTIO_BLK_S_IOERR : VIRTIO_BLK_S_OK;
> + ret = vhost_blk_set_status(blk, req->status, status);
> + if (!ret)
> + vhost_add_used_and_signal(>dev, vq, head,
> + VIRTIO
a kernel thread vs
scheduling a userspace thread. There's simply no way that that's a 60%
difference in performance.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
That seems like a reasonable trade off to me. I'm sure there's sufficient
incentive to patch Hyper-V for this at Microsoft...
Regards,
Anthony Liguori
Regards,
K. Y
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
likely to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To
. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
is it documented
. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
is it documented
to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list
. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
2. A lot of people would like to view (and Demo) it side-by-side.
3. Useful for BETA-testing of KVM
. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
2. A lot of people would like to view (and Demo) it side-by-side.
3. Useful for BETA-testing of KVM
Anthony Liguori wrote:
Joerg Roedel wrote:
The generic x86 code has to know if the specific implementation uses
Nested
Paging. In the generic code Nested Paging is called Hardware Assisted
Paging
(HAP) to avoid confusion with (future) HAP implementations of other
vendors.
This patch exports
obably return false here until the
patch that actually implements NPT support. Otherwise, the 7th patch in
this series breaks KVM for SVM.
Regards,
Anthony Liguori
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -
ol npt_enabled = false;
+static char *npt = "on";
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do
nasty things like implicitly cast a literal to a char *.
Regards,
Anthony Liguori
static void kvm_reput_irq(struct vcp
to start
running the install CDs for 32-bit and 64-bit Ubuntu, 32-bit OpenSuSE,
64-bit Fedora, and 32-bit Win2k8. I'll do a more thorough run of
kvm-test on Monday when I have a better connection to my machine.
Nice work!
Regards,
Anthony Liguori
Joerg
Here is the diffstat:
arch/x86/kvm
Anthony Liguori wrote:
Joerg Roedel wrote:
The generic x86 code has to know if the specific implementation uses
Nested
Paging. In the generic code Nested Paging is called Hardware Assisted
Paging
(HAP) to avoid confusion with (future) HAP implementations of other
vendors.
This patch exports
;
+static char *npt = on;
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do
nasty things like implicitly cast a literal to a char *.
Regards,
Anthony Liguori
static void kvm_reput_irq(struct vcpu_svm *svm);
@@ -415,6 +418,11
return false here until the
patch that actually implements NPT support. Otherwise, the 7th patch in
this series breaks KVM for SVM.
Regards,
Anthony Liguori
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -1734,6
to start
running the install CDs for 32-bit and 64-bit Ubuntu, 32-bit OpenSuSE,
64-bit Fedora, and 32-bit Win2k8. I'll do a more thorough run of
kvm-test on Monday when I have a better connection to my machine.
Nice work!
Regards,
Anthony Liguori
Joerg
Here is the diffstat:
arch/x86/kvm
,
Anthony Liguori
Ryo Tsuruta wrote:
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-mapper driver
,
Anthony Liguori
Ryo Tsuruta wrote:
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-mapper driver
mpatible than wouldn't xen-24.0 be compatible
too? I think the point was that you should either be checking for
'xen-3.x' or something more general that would accept anything >= xen-3.0.
Regards,
Anthony Liguori
But this is just a sanity check to make sure things are basically OK;
BUG_ON is h
xen-24.0 be compatible
too? I think the point was that you should either be checking for
'xen-3.x' or something more general that would accept anything = xen-3.0.
Regards,
Anthony Liguori
But this is just a sanity check to make sure things are basically OK;
BUG_ON is hardly nice error
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
d like an
8-bit identifier.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
identifier.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Avi Kivity wrote:
Anthony Liguori wrote:
Well please propose the virtio API first and then I'll adjust the PCI
ABI. I don't want to build things into the ABI that we never
actually end up using in virtio :-)
Move ->kick() to virtio_driver.
Then on each kick, all queues h
Avi Kivity wrote:
Anthony Liguori wrote:
Well please propose the virtio API first and then I'll adjust the PCI
ABI. I don't want to build things into the ABI that we never
actually end up using in virtio :-)
Move -kick() to virtio_driver.
Then on each kick, all queues have
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static void vp_notify(struct virtqueue *vq
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static void vp_notify(struct virtqueue *vq
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev->max_seg & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev->max_seg >> 8) & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev-max_seg 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev-max_seg 8) 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 2:
return (vdev-max_seg 16
decoder which
is goes against the earlier goal ;-)
Regards,
Anthony Liguori
I don't know about problems in other architectures, maybe mmio is better?
Dor.
Apologies in advance for my failure to pay attention.
thanks
ron
___
Lguest mailing list
[EMAIL
Dor Laor wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private
hypercalls and shared memory.
Regards,
Anthony Liguori
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->get()
Arnd Bergmann wrote:
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's
once as pv disk.
Ouch.
I have actually addressed this problem with a PV option rom for QEMU. I
expect to get time to submit the QEMU patches by the end of the year.
See http://hg.codemonkey.ws/extboot
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "un
showed up like a normal PCI device.
Am I misunderstanding what you're asking about?
Regards,
Anthony Liguori
I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fuss.
What is the use case you're thinking of? A semi-paravirt driver that
does
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in virtio_ring?
I
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in virtio_ring?
I
showed up like a normal PCI device.
Am I misunderstanding what you're asking about?
Regards,
Anthony Liguori
I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fuss.
What is the use case you're thinking of? A semi-paravirt driver that
does
disk.
Ouch.
I have actually addressed this problem with a PV option rom for QEMU. I
expect to get time to submit the QEMU patches by the end of the year.
See http://hg.codemonkey.ws/extboot
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
hypercalls and shared memory.
Regards,
Anthony Liguori
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Arnd Bergmann wrote:
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config-get() ops
Dor Laor wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private
decoder which
is goes against the earlier goal ;-)
Regards,
Anthony Liguori
I don't know about problems in other architectures, maybe mmio is better?
Dor.
Apologies in advance for my failure to pay attention.
thanks
ron
___
Lguest mailing list
[EMAIL
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 9e33fc4..c81e0f3 100644
--- a/drivers/
This patch moves virtio under the virtualization menu and changes virtio
devices to not claim to only be for lguest.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/Kconfig b/drivers/Kconfig
index f4076d9..d945ffc 100644
--- a/drivers/Kconfig
+++ b/drivers/K
1 - 100 of 218 matches
Mail list logo
