Rusty Russell wrote:
I don't think it'll be that bad; reset clears the device to unknown,
bar0 moves it from unknown-legacy mode, bar1/2/3 changes it from
unknown-modern mode, and anything else is bad (I prefer being strict so
we catch bad implementations from the beginning).
Will that work,
Rusty Russell wrote:
On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, May 04 2010, Rusty Russell wrote:
ISTR someone mentioning a desire for such an API years ago, so CC'ing
the
usual I/O suspects...
It would be nice to have a more fuller API
Michael S. Tsirkin wrote:
I took a stub at documenting CMD and FLUSH request types in virtio
block. Christoph, could you look over this please?
I note that the interface seems full of warts to me,
this might be a first step to cleaning them.
One issue I struggled with especially is how
Avi Kivity wrote:
On 01/05/2010 02:56 PM, Rusty Russell wrote:
Those should be the same for any sane interface. They are for classical
disk devices with larger block sizes (MO, s390 dasd) and also for the
now appearing 4k sector scsi disks. But in the ide world people are
concerned about
Avi Kivity wrote:
Physical block size is the what the logical block size would have been
is software didn't suck. In theory they should be the same, but since
compatibility reaons clamp the logical block size to 512, they have to
differ. A disk may have a physical block size of 4096 and
Anthony Liguori wrote:
Rusty Russell wrote:
The little-endian conversion of the balloon driver is a historical mistake
(no other driver does this). Let's not extend it to the stats.
I think the mistake is that the other drivers don't do that.
We cheat in qemu and assume that the guest is
Anthony Liguori wrote:
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 they're
implemented in the
Alan Cox wrote:
- Then, are we certain that there's no case where the tty layer will
call us with some lock held or in an atomic context ? To be honest,
I've totally lost track of the locking rules in tty land lately so it
might well be ok, but something to verify.
Some of the less
Amit Shah wrote:
I think strings are better as numbers for identifying protocols as you
can work without a central registry for the numbers then.
I like the way assigned numbers work: it's simpler to code, needs a
bitmap for all the ports that fits in nicely in the config space and
udev
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from including the
virtio-serial device driver so maybe we
Anthony Liguori wrote:
Richard W.M. Jones wrote:
Have you considered using a usb serial device? Something attractive
about it is that a productid/vendorid can be specified which means that
you can use that as a method of enumerating devices.
Hot add/remove is supported automagically.
Gleb Natapov wrote:
On Wed, Jul 29, 2009 at 01:14:18PM +0530, Amit Shah wrote:
But why do we want to limit the device to only one port? It's not too
complex supporting additional ones.
As I see it qemu and the kernel should provide the basic abstraction for
the userspace to go do its
Daniel P. Berrange wrote:
I expect the first problem you'll run into is that copy/paste daemon has
to run as an unprivileged user but /dev/vmch3 is going to be owned by
root. You could set udev rules for /dev/vmch3 but that's pretty
terrible IMHO.
I don't think that's not too bad,
Amit Shah wrote:
A few sample uses for a vmchannel are to share the host and guest
clipboards (to allow copy/paste between a host and a guest), to
lock the screen of the guest session when the vnc viewer is closed,
to find out which applications are installed on a guest OS even when
the guest
Amit Shah wrote:
On (Wed) Jun 24 2009 [17:40:49], Jamie Lokier wrote:
Amit Shah wrote:
A few sample uses for a vmchannel are to share the host and guest
clipboards (to allow copy/paste between a host and a guest), to
lock the screen of the guest session when the vnc viewer is closed
Amit Shah wrote:
On (Wed) Jun 24 2009 [18:50:02], Jamie Lokier wrote:
Amit Shah wrote:
On (Wed) Jun 24 2009 [17:40:49], Jamie Lokier wrote:
Amit Shah wrote:
A few sample uses for a vmchannel are to share the host and guest
clipboards (to allow copy/paste between a host
Avi Kivity wrote:
On 06/16/2009 09:32 PM, Jamie Lokier wrote:
Avi Kivity wrote:
Another issue is enumeration. Guests will present their devices in the
order they find them on the pci bus (of course enumeration is guest
specific). So if I have 2 virtio controllers the only way I can
Avi Kivity wrote:
If management apps need to hard-code which slots are available on
different targets and different qemu versions, or restrictions on which
devices can use which slots, or knowledge that some devices can be
multi-function, or ... anything like that is just lame.
You
Avi Kivity wrote:
Another issue is enumeration. Guests will present their devices in the
order they find them on the pci bus (of course enumeration is guest
specific). So if I have 2 virtio controllers the only way I can
distinguish between them is using their pci slots.
virtio
Mark McLoughlin wrote:
After libvirt has done -drive file=foo... it should dump the machine
config and use that from then on.
Right - libvirt then wouldn't be able to avoid the complexity of merging
any future changes into the dumped machine config.
As long as qemu can accept a machine
Mark McLoughlin wrote:
Worst case we hardcode those numbers (gasp, faint).
Maybe we can just add the open slots to the -help output. That'd be nice
and clean.
Make them part of the machine configuration.
After all, they are part of the machine configuration, and ACPI, BIOS
etc. need to
Paul Brook wrote:
caps can be anywhere, but we don't expect it to change during machine
execution lifetime.
Or I am just confused by the name pci_device_load ?
Right. So I want to load an image and it has capability X at offset Y.
wmask has to match. I don't want to assume that
Michael S. Tsirkin wrote:
I think the right long term answer to all this is a way to get QEMU to
dump it's current machine configuration in glorious detail as a file
which can be reloaded as a machine configuration.
And then we'll have the same set of problems there.
We will, and the
23 matches
Mail list logo
