Hi Michael,
On Mon, Sep 15, 2014 at 1:20 AM, Michael S. Tsirkin wrote:
> On Sun, Sep 14, 2014 at 08:29:33PM -0700, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> See https://issues.oasis-open.org/browse/VIRTIO-16 although it
>> was prematurely closed.
>
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
From: Anthony Liguori
See https://issues.oasis-open.org/browse/VIRTIO-16 although it
was prematurely closed.
Red Hat has non-redistributable Windows drivers and Microsoft
will not allow anyone else to WHQL certify drivers using that
vendor ID. That makes it impossible to use virtio drivers
From: Anthony Liguori
If MSI-X initialization fails after setting msix_enabled = 1, then
the device is left in an inconsistent state. This would normally
only happen if there was a bug in the device emulation but it still
should be handled correctly.
Cc: Matt Wilson
Cc: Rusty Russell
Cc
We have received numerous requests to extend the CFP deadline and so
we are happy to announce that the CFP deadline has been moved by two
weeks to August 4th.
=
KVM Forum 2013: Call For Participation
October 21-23, 2013 - Edinburgh I
"Michael S. Tsirkin" writes:
> On Thu, May 30, 2013 at 08:40:47AM -0500, Anthony Liguori wrote:
>> Stefan Hajnoczi writes:
>>
>> > On Thu, May 30, 2013 at 7:23 AM, Rusty Russell
>> > wrote:
>> >> Anthony Liguori writes:
>> >
Rusty Russell writes:
> Anthony Liguori writes:
>> Forcing a guest driver change is a really big
>> deal and I see no reason to do that unless there's a compelling reason
>> to.
>>
>> So we're stuck with the 1.0 config layout for a very long time.
>
Stefan Hajnoczi writes:
> On Thu, May 30, 2013 at 7:23 AM, Rusty Russell wrote:
>> Anthony Liguori writes:
>>> Rusty Russell writes:
>>>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>>>>> FWIW, I think what's m
Rusty Russell writes:
> Anthony Liguori writes:
>> Rusty Russell writes:
>>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>>>> FWIW, I think what's more interesting is using vhost-net as a networking
>>>> backend wi
"Michael S. Tsirkin" writes:
> On Wed, May 29, 2013 at 09:16:39AM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" writes:
>> > I'm guessing any compiler that decides to waste memory in this way
>> > will quickly get dropped by users and
"Michael S. Tsirkin" writes:
> On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
>> Rusty Russell writes:
>>
>> > Anthony Liguori writes:
>> >> The headers say they are BSD licensed... but they include a GPLv2+
>> >> h
o_balloon_stat is not padded and indeed has
> an __attribute__((__packed__)) in the spec.
Not that these structures are actually used for something.
We store the config in these structures so they are actually used for
something.
The proposed structures only serve as a way to express offsets.
"Michael S. Tsirkin" writes:
> On Wed, May 29, 2013 at 07:52:37AM -0500, Anthony Liguori wrote:
>> 1) C makes no guarantees about structure layout beyond the first
>>member. Yes, if it's naturally aligned or has a packed attribute,
>>GCC does the righ
Rusty Russell writes:
> Anthony Liguori writes:
>> The headers say they are BSD licensed... but they include a GPLv2+
>> header. Doesn't make a lot of sense, does it?
>
> It makes perfect sense: you're overthinking it. It just means that
> copying the BSD h
Rusty Russell writes:
> "Michael S. Tsirkin" writes:
>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
>>> "Michael S. Tsirkin" writes:
>>>
>>> > On Fri, May 24, 2013 at 05:41:11PM +0800, Jason Wang wrote:
>>&g
Rusty Russell writes:
> Anthony Liguori writes:
>> "Michael S. Tsirkin" writes:
>>> +case offsetof(struct virtio_pci_common_cfg, device_feature_select):
>>> +return proxy->device_feature_select;
>>
>> Oh dear no... Please use
"Michael S. Tsirkin" writes:
> On Tue, May 28, 2013 at 12:15:16PM -0500, Anthony Liguori wrote:
>> > @@ -455,6 +462,226 @@ static void virtio_pci_config_write(void *opaque,
>> > hwaddr addr,
>> > }
>> > }
>> >
>> > +stat
irtIODevice *vdev = proxy->vdev;
> +
> +uint64_t low = 0xull;
> +
> +switch (addr) {
> +case offsetof(struct virtio_pci_common_cfg, device_feature_select):
> +return proxy->device_feature_select;
Oh dear no... Please use defines like the rest of QEMU.
>From a Q
Rusty Russell writes:
> Anthony Liguori writes:
>> Paolo Bonzini writes:
>>
>>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>>> > My fault. I should have looked at linux/types.h (actually asm-generic/).
>>>>
>>>> Not r
"Michael S. Tsirkin" writes:
> On Sun, May 26, 2013 at 07:55:25PM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> >> Paolo Bonzini writes:
&
"Michael S. Tsirkin" writes:
> On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> Paolo Bonzini writes:
>>
>> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> >> > My fault. I should have looked at linux/types.h (
Paolo Bonzini writes:
> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> > My fault. I should have looked at linux/types.h (actually asm-generic/).
>>
>> Not really, __uX appear in the headers that were posted.
Which is a problem because this is a reserved namespace in C99.
>> What I'm
rking backend is a distraction,
> and confusing to users.
> In any case, I'd like to see virtio-blk dataplane replace
> non dataplane first. We don't want two copies of
> virtio-net in qemu.
100% agreed.
Regards,
Anthony Liguori
>
>> >
>> >
>>
hanges in Patch-v2:
>- Move ->get_features() assignment to virtio_scsi_init() instead of
> virtio_scsi_init_common()
Any reason we're not doing this as a QOM base class?
Similiar to how the in-kernel PIT/PIC work using a common base class...
Regards,
Anthony Liguori
>
> Unfortunately, I've not been able to get back to the conversion
> requested by Paolo for a standalone vhost-scsi PCI device.
Is your git repo above up to date? Perhaps I can find someone to help
out..
> At this point my hands are still full with iSER-target for-3.9 kernel
> code ove
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
___
Virtualization mailing list
Virtualization@lists.linux-foun
ture, but it seems they're blessed in PCI
> 2.3.
2.3 was standardized in 2002. Are we confident that vendor extensions
play nice with pre-2.3 OSes like Win2k, WinXP, etc?
I still think it's a bad idea to rely on something so "new" in something
as fundamental as virtio-pci unl
se new features because we need to adjust
>> migration state accordingly.
>
> Why does migration need adjustments?
Because there is additional state in the "new" layout. We need to
understand whether a guest is relying on that state or not.
For instance, extended virt
Avi Kivity writes:
> On 10/09/2012 05:16 AM, Rusty Russell wrote:
>> Anthony Liguori writes:
>>> We'll never remove legacy so we shouldn't plan on it. There are
>>> literally hundreds of thousands of VMs out there with the current virtio
>>> driver
Rusty Russell writes:
> Anthony Liguori writes:
>> We'll never remove legacy so we shouldn't plan on it. There are
>> literally hundreds of thousands of VMs out there with the current virtio
>> drivers installed in them. We'll be supporting them for a very
Rusty Russell writes:
> Anthony Liguori writes:
>> Gerd Hoffmann writes:
>>
>>> Hi,
>>>
>>>>> So we could have for virtio something like this:
>>>>>
>>>>> Capabilities: [??] virtio-regs:
>>>>&g
ISR as PIO as it is a fast path.
>
> No problem if we allow to have both legacy layout and new layout at the
> same time. Guests can continue to use ISR @ BAR0 in PIO space for
> existing virtio devices, even in case they want use mmio for other
> registers -> all fine.
&
d guests without
> MSI-X support need this, and we don't need to worry that much when
> designing something new ...
It wasn't that long ago that MSI-X wasn't supported.. I think we should
continue to keep ISR as PIO as it is a fast path.
Regards,
Rusty Russell writes:
> (Topic updated, cc's trimmed).
>
> Anthony Liguori writes:
>> Rusty Russell writes:
>>> 4) The only significant change to the spec is that we use PCI
>>>capabilities, so we can have infinite feature bits.
>>>(see
This maps really nicely to non-PCI transports 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
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
proposing.
In this case, we should simply say that with the feature 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/Kc
;t matter when it doesn't agree
with all of the existing implementations.
Users use implementations, not specifications. The specification really
ought to be changed here.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
d by one
device is a bit silly too.
So I would be in favor of dropping/squashing 3/5 and radically simplifying how
this was exposed to the user.
I would just take qemu_vhost_scsi_opts and make them device properties.
Regards,
Anthony Liguori
"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 questio
ret = vhost_blk_set_status(blk, req->status, status);
> + if (!ret)
> + vhost_add_used_and_signal(&blk->dev, vq, head,
> + VIRTIO_BLK_ID_BYTES);
> + break;
> + default:
> + pr_warn("Unsupported request type %d\n", hdr->type);
> + vhost_discard_vq_desc(vq, 1);
> + ret = -EFAULT;
> + break;
> + }
There doesn't appear to be any error handling in the event that
vhost_blk_io_submit fails. It would appear that you leak the ring queue
entry since you never push anything onto the used queue.
I think you need to handle io_submit() failing too with EAGAIN. Relying
on min nr_events == queue_size seems like a dangerous assumption to me
particularly since queue_size tends to be very large and max_nr_events
is a fixed size global pool.
To properly handle EAGAIN, you effectively need to implement flow
control and back off reading the virtqueue until you can submit requests again.
Of course, the million dollar question is why would using AIO in the
kernel be faster than using AIO in userspace?
When using eventfd, there is no heavy weight exit on the notify path.
It should just be the difference between scheduling a kernel thread vs
scheduling a userspace thread. There's simply no way that that's a 60%
difference in performance.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 07/18/2012 11:47 AM, James Bottomley wrote:
On Wed, 2012-07-18 at 11:00 -0500, Anthony Liguori wrote:
Of course: Think about the consequences: you want to upgrade one array
on your SAN. You definitely don't want to shut down your entire data
centre to achieve it. In place upgrad
On 07/18/2012 10:53 AM, Christoph Hellwig wrote:
On Wed, Jul 18, 2012 at 08:42:21AM -0500, Anthony Liguori wrote:
If you add support for a new command, you need to provide userspace
a way to disable this command. If you change what gets reported for
VPD, you need to provide userspace a way to
On 07/17/2012 04:50 PM, Nicholas A. Bellinger wrote:
On Tue, 2012-07-17 at 13:55 -0500, Anthony Liguori wrote:
On 07/17/2012 10:05 AM, Michael S. Tsirkin wrote:
On Wed, Jul 11, 2012 at 09:15:00PM +, Nicholas A. Bellinger wrote:
It still seems not 100% clear whether this driver will
e to make it depend on CONFIG_STAGING.
Then we don't commit to an ABI.
I think this is a good idea. Even if it goes in, a really clear policy would be
needed wrt the userspace ABI.
While tcm_vhost is probably more useful than vhost_blk, it's a much more complex
ABI to maintain.
Re
are lots of ways to try to solve this--like try to reuse the kernel code
in userspace or just improving the userspace code. If we were able to make the
two paths identical, then I strongly suspect there'd be no point in having
tcm_vhost anyway.
Regards,
Anthony Liguori
so that it is not
t and vhost-scsi isn't going to solve that problem for us.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
iptor layouts? As
long as the layout is specified clearly it makes everyone's lives
easier to use a strict descriptor layout.
I hate to just change the spec here but I don't see a better option.
Regards,
Anthony Liguori
The only reason I can think of is that virtio should work over
tr
On 03/19/2012 06:52 PM, Rusty Russell wrote:
On Mon, 19 Mar 2012 17:13:06 -0500, Anthony Liguori
wrote:
Maybe just make this a hidden option like x-miio?
x-violate-the-virtio-spec-to-trick-old-linux-drivers-into-working-on-power?
"To configure the device, we use the first I/O regi
On 03/19/2012 04:29 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 04:07:45PM -0500, Anthony Liguori wrote:
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual
fault but causes segfaults in memory.c
when enabled. Thus an RFC until I figure out what's wrong.
Doesn't this violate the virtio-pci spec?
Making the same vendor/device ID have different semantics depending on a magic
flag in QEMU seems like a pretty bad idea to me.
Regards,
On 01/11/2012 02:14 PM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 01:42:39PM -0600, Anthony Liguori wrote:
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it'
On 01/11/2012 11:08 AM, Michael S. Tsirkin wrote:
Not sure what you mean. Using VQ is DMA which is pretty common for PCI.
Do you know of a network device that obtains it's mac address via a DMA
transaction?
Regards,
Anthony Li
On 01/11/2012 09:45 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:28:27AM -0600, Anthony Liguori wrote:
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
This is similar to what we have now. But it's still buggy
On 01/11/2012 09:21 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 09:15:49AM -0600, Anthony Liguori wrote:
This is similar to what we have now. But it's still buggy: e.g. if guest
updates MAC byte by byte, we have no way to know when it's done doing
so.
This is no differ
On 01/11/2012 09:12 AM, Michael S. Tsirkin wrote:
On Wed, Jan 11, 2012 at 07:30:34AM -0600, Anthony Liguori wrote:
On 01/10/2012 06:25 PM, Rusty Russell wrote:
On Tue, 10 Jan 2012 19:03:36 +0200, "Michael S. Tsirkin"
wrote:
On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Rus
st, in
the spec). That makes it a big change, and it'll take longer to
develop, but makes it easy in the long run to differentiate legacy and
modern virtio.
Ack. Long live virtio2! :-)
Regards,
Anthony Liguori
Thoughts?
Rusty.
___
On 11/03/2011 09:31 AM, Michael S. Tsirkin wrote:
On Thu, Nov 03, 2011 at 08:49:31AM -0500, Anthony Liguori wrote:
On 11/03/2011 08:45 AM, Avi Kivity wrote:
On 11/03/2011 03:38 PM, Anthony Liguori wrote:
We could use a better agreement on the processor for making virtio
changes. Should it
her patch that would add
> something similar into virtio-net. My plan was to enable collecting
> statistics regarding memory, network and disk usage in a simple manner
> without accessing guests.
Why not just add an interface that lets you read files from a guest
either via a guest agent (like qemu-ga) or a purpose built PV device?
That would let you access the guest's full sysfs which seems to be quite
a lot more useful long term than adding a bunch of specific interfaces.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
On 01/05/2011 02:05 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 05, 2011 at 01:28:34PM -0600, Anthony Liguori wrote:
>
>> On 01/05/2011 01:17 PM, Michael S. Tsirkin wrote:
>>
>>> We sometimes need to map between the virtio device and
>>> the given pci
On 01/05/2011 01:38 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 05, 2011 at 01:28:34PM -0600, Anthony Liguori wrote:
>
>> On 01/05/2011 01:17 PM, Michael S. Tsirkin wrote:
>>
>>> We sometimes need to map between the virtio device and
>>> the given pci
.
At any rate, a better commit message would be helpful in explaining the
need for this.
Regards,
Anthony Liguori
> Supply softlinks between these to make it possible.
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> Gleb, could you please ack that this patch below
> will be e
On 11/12/2010 06:14 AM, Ian Molton wrote:
> On 10/11/10 17:47, Anthony Liguori wrote:
>> On 11/10/2010 11:22 AM, Ian Molton wrote:
>>> Ping ?
>>
>> I think the best way forward is to post patches.
>
> I posted links to the git trees. I can post patches, but the
e coding style issues and make the code fit into QEMU.
Dropping a bunch of junk into target-i386/ is not making the code fit
into QEMU.
If you post just what you have now in patch form, I can try to provide
more concrete advice ignoring the coding style problems.
Regards,
Anthony
e that happens to compile as part of qemu even though it
doesn't actually integrate with qemu in any meaningful way is not
integrating. That's just build system manipulation.
Regards,
Anthony Liguori
> I added one virtio driver and a seperate offscreen renderer. it
> touches th
On 11/01/2010 10:49 AM, Ian Molton wrote:
> On 01/11/10 13:21, Anthony Liguori wrote:
>> On 11/01/2010 05:42 AM, Avi Kivity wrote:
>>> On 10/28/2010 03:52 PM, Ian Molton wrote:
>>>> On 28/10/10 15:24, Avi Kivity wrote:
>
>>> Waiting for a response i
) but integrating into QEMU is going to
require an awful lot of the existing code to be rewritten. Keeping it
separate has the advantage of allowing something to Just Work as an
interim solution as we wait for proper support in Spice.
Regards,
Anthony Liguori
>
>> Regards,
>
multiple applications trying to use GL but
AFAICT, this is not supported in the current model.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
nd trip.
The alternative proposal is Spice which so far noone has mentioned.
Right now, Spice seems to be taking the right approach to guest 3d support.
Regards,
Anthony Liguori
>I understand others are skeptical,
> but this seems simple and if it works and you're happy to main
On 10/28/2010 02:50 PM, Ian Molton wrote:
> On 28/10/10 15:43, Anthony Liguori wrote:
>> On 10/28/2010 09:24 AM, Avi Kivity wrote:
>>> On 10/28/2010 01:54 PM, Ian Molton wrote:
>>
>>>> True, but then all that would prove is that I can write a spec to
>&g
by people with a deeper understanding of the problem space.
Regards,
Anthony Liguori
>> The code is proof of concept. the kernel bit is pretty simple, but
>> I'd like to get some idea of whether the rest of the code will be
>> accepted given that theres not much point in having a
On 06/30/2010 05:31 PM, Michael S. Tsirkin wrote:
> On Wed, Jun 30, 2010 at 05:08:11PM -0500, Anthony Liguori wrote:
>
>> On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
>>
>>> On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
>>>
o do that.
I don't think it makes sense for vhost to do this. These guests are so
old that they don't have the requisite features to achieve really high
performance anyway.
I've always thought making vhost totally transparent was a bad idea and
this is one of the reasons. We can do a lot of ugly things in userspace
that we shouldn't be doing in the kernel.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
ure as a field in
/proc/cpuinfo. There's also a /sys/hypervisor where such information
could go.
Regards,
Anthony Liguori
> Regards
> Chetan Loke
> --
> To unsubscribe from this list: send the line "unsubscribe
ueue *q)
> }
>
> if (issued)
> - virtqueue_kick(vblk->vq);
> + virtqueue_kick(vblk->vq,&vblk->lock);
> }
>
Shouldn't it be possible to just drop the lock before invoking
virtqueue_kick() and reacquire it afterwards?
x straight away would be simpler, while
> this might allow the host to specilatively look up the buffer and handle
> it, without waiting for the kick.
>
It should be okay as long as you don't update idx for partial vectors.
Regards,
Anthony Liguori
_
> There has been previous discussion of virtio, however while virtio is
> good for exporting guest memory, it's not ideal for importing memory
> into a guest.
>
virtio is a DMA-based API which means that it doesn't assume cache
coherent shared memory. The PCI transpor
ally, two guest CPUs
> should be able to transmit and receive on separate queues of the
> adapter without ever having to access any shared resources.
>
Multiqueue adds another dimension but I think your approach is pretty
much right on the money. Have multiple fds for each queue
to create these initial
file descriptors. We'll have to think about how we can make this
integrate well so that the syntax isn't clumsy.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
+struct virtio_balloon_stat
>> +{
>> +__le16 tag;
>> +__le32 val;
>> +};
>>
>
> Is 32 bits sufficient? A big machine might get over 4bn faults, and certainly
> 4 TB of memory isn't t
Rusty Russell wrote:
> On Wed, 11 Nov 2009 08:22:42 am Anthony Liguori wrote:
>
>> Rusty Russell wrote:
>>
>>> On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
>>>
>>>
>>>> A simpler approach is to collect memory statisti
o request that stats be collected and then you
need to tell the hypervisor about the stats that were collected. You
don't need any real correlation between requests and stat reports either.
This really models how target/actual work and I think it suggests that
we want to reuse that mechani
Avi Kivity wrote:
> On 11/10/2009 04:36 PM, Anthony Liguori wrote:
>>
>>> A stats vq might solve this more cleanly?
>>
>> actual and target are both really just stats. Had we implemented
>> those with a vq, I'd be inclined to agree with you but since th
ree with you but since they're
implemented in the config space, it seems natural to extend the config
space with other stats.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
if (virtio_has_feature(vdev, feature)) {
> + vdev->config->set(vdev, offset, &value, sizeof(value));
>
I think this bit assumes a little endian guest. We shouldn't make that
assumption.
For virtio kernel patches, please CC the virtualization list and Rusty
as h
virtio infrastructure.
vhost-net should really be it's own qdev device. I don't see very much
code reuse happening right now so I don't understand why it's not that
way currently.
Regards,
Anthony Liguori
___
Virtualization mail
x27;ing ability for transport features.
If you need to change transport features, it suggests you're modeling
things incorrectly and should be supplying an alternative transport
implementation.
Regards,
Anthony Liguori
___
Virtualization maili
Christoph Hellwig wrote:
> On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
>
>> Which patches are those?
>>
>
> http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9
>
> and
>
> http://repo.or
d be great if Anthony could take those ASAP.
>
Which patches are those?
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
H. Peter Anvin wrote:
> On 09/18/2009 10:55 AM, Anthony Liguori wrote:
>
>> I fail to see how this is at all relevant. This is a virtual machine,
>> we're presenting virtual hardware that behaves like a serial device.
>> Where web servers fit in is completel
re presenting virtual hardware that behaves like a serial device.
Where web servers fit in is completely beyond me.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
g SNMP.
>
This device cannot be implemented as-is in userspace because it depends
on DMA which precludes the use of something like uio_pci. We could
modify the device to avoid dma if the feeling was that there was no
interest in putting this in the kernel.
Regards,
Anthony Liguori
___
can just open /dev/vcon/$name then.
That works equally well. I don't necessarily think that naming is more
useful.
Regards,
Anthony Liguori
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Amit Shah wrote:
> On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote:
>
>> Amit Shah wrote:
>>
>>> Hey Greg,
>>>
>>> Can you tell me how this could work out -- each console port could have
>>> a "role" string associated w
That's probably not what we want. I imagine what we want is:
/dev/ttyV0
/dev/ttyV1
/dev/ttyVN
And then we want:
/sys/class/virtio-console/ttyV0/name -> "org.qemu.clipboard"
Userspace can detect when new virtio-consoles appear via udev events.
When it sees a new
Michael S. Tsirkin wrote:
> On Mon, Sep 14, 2009 at 12:15:29PM -0500, Anthony Liguori wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> Hi!
>>> pci bus reset does not seem to clear pci config registers, such as BAR
>>> registers, or memory s
st pci devices reset their config space in their reset
callbacks.
I would think that making most of the config space (if not the entire)
qdev properties would make sense. You can then get reset for free and
it's possible for users to tweak things like class codes universally.
Regard
Amit Shah wrote:
> On (Fri) Sep 11 2009 [12:26:16], Anthony Liguori wrote:
>
>> Amit Shah wrote:
>>
>>> Right; there was some discussion about this. A few alternatives were
>>> suggested like
>>>
>>> - udev scripts to create symli
/dev/virtio-console/com/redhat/clipboard
>
> which again can be created by udev scripts
>
And I dislike all of them. What I'd rather have is these devices
exposed as tty's with a sys attribute that exposed the name of the device.
This is not all that different to how
1 - 100 of 363 matches
Mail list logo
