"Michael S. Tsirkin" wrote:
> On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote:
>> > > Right. The only real challenge is dealing with legacy save/restore and
>> > > command line syntax. For save/restore, we can possibly have a dummy
>> > > device that can split the VirtioPCI device sta
On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote:
> > > Right. The only real challenge is dealing with legacy save/restore and
> > > command line syntax. For save/restore, we can possibly have a dummy
> > > device that can split the VirtioPCI device state from the virtio device
> > > st
> > Right. The only real challenge is dealing with legacy save/restore and
> > command line syntax. For save/restore, we can possibly have a dummy
> > device that can split the VirtioPCI device state from the virtio device
> > states and do the right thing.
> >
> > I'm not sure what we should do
On 03/23/10 11:47, Michael S. Tsirkin wrote:
I'm not sure what we should do for command line syntax. We can keep
-drive working as is. Do we need to support -device based creation? I
don't think we've really considered what to do in a situation like this.
If we need to change command line b
On Mon, Mar 22, 2010 at 08:16:01PM -0500, Anthony Liguori wrote:
> On 03/22/2010 07:49 PM, Paul Brook wrote:
>>> Solutions:
>>> - VirtIOPCIBus and hang devices from there (anthony). Why? because
>>> this is a simulated pci bus, we can implement the features that we
>>> need (not full pci) in
On 03/22/2010 07:49 PM, Paul Brook wrote:
Solutions:
- VirtIOPCIBus and hang devices from there (anthony). Why? because
this is a simulated pci bus, we can implement the features that we
need (not full pci) in the three showed architectures. We will have
VirtIOPCIBLock everywhere, and i
On 03/22/2010 04:00 PM, Paul Brook wrote:
On 03/22/2010 11:16 AM, Paul Brook wrote:
But look at the lguest virtio implement. We would definitely model a
VirtIOBus if we implemented something like that in qemu. VirtIO really
is designed to be a bus.
When you say "bus" you actua
>Solutions:
>- VirtIOPCIBus and hang devices from there (anthony). Why? because
> this is a simulated pci bus, we can implement the features that we
> need (not full pci) in the three showed architectures. We will have
> VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will
> h
"Michael S. Tsirkin" wrote:
> On Mon, Mar 22, 2010 at 03:51:43PM +, Paul Brook wrote:
>> > > It's a classic OOP problem.
>> > >
>> > > VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState
>> > >
>> > > VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State.
>> > >
>> > > But VirtIODevic
> On 03/22/2010 11:16 AM, Paul Brook wrote:
> >> But look at the lguest virtio implement. We would definitely model a
> >> VirtIOBus if we implemented something like that in qemu. VirtIO really
> >> is designed to be a bus.
> >
> > When you say "bus" you actually mean point-point connection, righ
On 03/22/2010 11:16 AM, Paul Brook wrote:
But look at the lguest virtio implement. We would definitely model a
VirtIOBus if we implemented something like that in qemu. VirtIO really
is designed to be a bus.
When you say "bus" you actually mean point-point connection, right[1]?
I don't se
On Mon, Mar 22, 2010 at 03:51:43PM +, Paul Brook wrote:
> > > It's a classic OOP problem.
> > >
> > > VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState
> > >
> > > VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State.
> > >
> > > But VirtIODevice is-a VirtIOPCI device isn't always t
> But look at the lguest virtio implement. We would definitely model a
> VirtIOBus if we implemented something like that in qemu. VirtIO really
> is designed to be a bus.
When you say "bus" you actually mean point-point connection, right[1]?
I don't see anything in virtio that allows arbitration
> > It's a classic OOP problem.
> >
> > VirtIOBlock is-a VirtIODevice, VirtIODevice is-a DeviceState
> >
> > VirtIOPCI is-a PCIDevice, PCIDevice is-a Device State.
> >
> > But VirtIODevice is-a VirtIOPCI device isn't always true so it can't be
> > an is-a relationship. Initially, this was true and
On 03/22/2010 10:17 AM, Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 10:03:29AM -0500, Anthony Liguori wrote:
On 03/22/2010 09:50 AM, Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote:
On 03/22/2010 08:30 AM, Paul Brook wrote:
On Mon, Mar 22, 2010 at 10:03:29AM -0500, Anthony Liguori wrote:
> On 03/22/2010 09:50 AM, Michael S. Tsirkin wrote:
>> On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote:
>>
>>> On 03/22/2010 08:30 AM, Paul Brook wrote:
>>>
> A VirtIOBlock device cannot be a VirtIODevice
On 03/22/2010 09:50 AM, Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote:
On 03/22/2010 08:30 AM, Paul Brook wrote:
A VirtIOBlock device cannot be a VirtIODevice while being a
VirtIOPCIProxy (proxy is a poor name, btw).
It really ought to be:
On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote:
> On 03/22/2010 08:30 AM, Paul Brook wrote:
>>> A VirtIOBlock device cannot be a VirtIODevice while being a
>>> VirtIOPCIProxy (proxy is a poor name, btw).
>>>
>>> It really ought to be:
>>>
>>> DeviceState -> VirtIODevice -> VirtIO
On 03/22/2010 08:30 AM, Paul Brook wrote:
A VirtIOBlock device cannot be a VirtIODevice while being a
VirtIOPCIProxy (proxy is a poor name, btw).
It really ought to be:
DeviceState -> VirtIODevice -> VirtIOBlock
and:
PCIDevice -> VirtIOPCI : implements VirtIOBus
The interface between the
> A VirtIOBlock device cannot be a VirtIODevice while being a
> VirtIOPCIProxy (proxy is a poor name, btw).
>
> It really ought to be:
>
> DeviceState -> VirtIODevice -> VirtIOBlock
>
> and:
>
> PCIDevice -> VirtIOPCI : implements VirtIOBus
>
> The interface between the VirtIODevice and VirtIO
On Mon, Mar 22, 2010 at 02:13:48AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
> >> Michael S. Tsirkin wrote:
> >> > That's version 1 of my patch. Version 2 removed even need for macro
> >> > completely by moving alloc
On 03/21/2010 08:06 PM, Juan Quintela wrote:
"Michael S. Tsirkin" wrote:
On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
Michael S. Tsirkin wrote:
That's version 1 of my patch. Version 2 removed even need for macro
completely by moving allocations to the caller
"Michael S. Tsirkin" wrote:
> On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
>> Michael S. Tsirkin wrote:
>> > That's version 1 of my patch. Version 2 removed even need for macro
>> > completely by moving allocations to the caller.
>>
>> The downside of moving allocations are: (1)
"Michael S. Tsirkin" wrote:
> On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
>> Michael S. Tsirkin wrote:
>> > That's version 1 of my patch. Version 2 removed even need for macro
>> > completely by moving allocations to the caller.
>>
>> The downside of moving allocations are: (1)
On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > That's version 1 of my patch. Version 2 removed even need for macro
> > completely by moving allocations to the caller.
>
> The downside of moving allocations are: (1) it's one more call in the
> caller,
On Sun, Mar 21, 2010 at 06:11:43PM +, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > That's version 1 of my patch. Version 2 removed even need for macro
> > completely by moving allocations to the caller.
>
> The downside of moving allocations are: (1) it's one more call in the
> caller,
Michael S. Tsirkin wrote:
> That's version 1 of my patch. Version 2 removed even need for macro
> completely by moving allocations to the caller.
The downside of moving allocations are: (1) it's one more call in the
caller, to allocate the type, (2) it needs a virtual destructor for
each type to f
On Fri, Mar 19, 2010 at 01:41:59AM +, Jamie Lokier wrote:
> Juan Quintela wrote:
> > vstrucut virtio_common *create_virtio_comon(, size we really want);
> > Again, this implements superclass/subclass as well as you can implemnt
> > it in C.
>
> It would be more type-safe for create_virtio_
Juan Quintela wrote:
> vstrucut virtio_common *create_virtio_comon(, size we really want);
> Again, this implements superclass/subclass as well as you can implemnt
> it in C.
It would be more type-safe for create_virtio_common() to be a macro
taking the subclass *type* rather than sizeof.
And
On 03/18/2010 11:36 AM, Gerd Hoffmann wrote:
Hi,
But I still think that this is independent that VirtIO being 1st (or
not) memer of VirtIOBlock.
There is no strong reason for this other than memory allocation. As
long as virtio_common_init() does the allocation there is no way
around Vir
"Michael S. Tsirkin" wrote:
> On Thu, Mar 18, 2010 at 06:08:06PM +0100, Juan Quintela wrote:
>> Gerd Hoffmann wrote:
>
> The whole '1st place' hack is really not necessary, if we know the
> offset we can use container_of.
container_of() don't cut mustard. The whole point is that virtio-pci
cod
On Thu, Mar 18, 2010 at 06:08:06PM +0100, Juan Quintela wrote:
> Gerd Hoffmann wrote:
> > Hi,
> >
> >> But I still think that this is independent that VirtIO being 1st (or
> >> not) memer of VirtIOBlock.
> >
> > There is no strong reason for this other than memory allocation. As
> > long as vir
On Thu, Mar 18, 2010 at 03:21:59PM +0100, Juan Quintela wrote:
> > My patch removes lines of code. It is actually simpler than
> > what we had: no casts, no assumptions.
>
> It is more complex. You need to add a new offset field to be able to
> free it in common code. To add insult to injury, yo
Gerd Hoffmann wrote:
> Hi,
>
>> But I still think that this is independent that VirtIO being 1st (or
>> not) memer of VirtIOBlock.
>
> There is no strong reason for this other than memory allocation. As
> long as virtio_common_init() does the allocation there is no way
> around VirtIODevice bei
Hi,
But I still think that this is independent that VirtIO being 1st (or
not) memer of VirtIOBlock.
There is no strong reason for this other than memory allocation. As
long as virtio_common_init() does the allocation there is no way around
VirtIODevice being the first member. If this cha
Gerd Hoffmann wrote:
> Hi,
>
>>> I think we should move away from struct layout assumptions that
>>> DO_UPCAST enforces, and to use container_of where possible.
>>> I'll post a series shortly that do this for virtio.
>>
>> Not in this case. qdev needs it to be in that order, and that will not
>
Hi,
I think we should move away from struct layout assumptions that
DO_UPCAST enforces, and to use container_of where possible.
I'll post a series shortly that do this for virtio.
Not in this case. qdev needs it to be in that order, and that will not
change without changing everything again
"Michael S. Tsirkin" wrote:
> On Thu, Mar 18, 2010 at 02:43:04PM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Thu, Mar 18, 2010 at 12:53:06PM +0100, Juan Quintela wrote:
>> >>
>> >> You cant. Your trick of creating of mallocking in the caller the struct
>> >> don't work fo
On Thu, Mar 18, 2010 at 02:43:04PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Thu, Mar 18, 2010 at 12:53:06PM +0100, Juan Quintela wrote:
> >>
> >> You cant. Your trick of creating of mallocking in the caller the struct
> >> don't work for qdev. qdev is the one that create
"Michael S. Tsirkin" wrote:
> On Thu, Mar 18, 2010 at 12:53:06PM +0100, Juan Quintela wrote:
>>
>> You cant. Your trick of creating of mallocking in the caller the struct
>> don't work for qdev. qdev is the one that creates it. Again, any other
>> implementation is going to be more complex for
On Thu, Mar 18, 2010 at 12:53:06PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Thu, Mar 18, 2010 at 09:36:15AM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" wrote:
> >>
> >> >> Look at the rest of hw/*.
> >> >
> >> > I think you mean that a similar assumption is ma
"Michael S. Tsirkin" wrote:
> On Thu, Mar 18, 2010 at 09:36:15AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>>
>> >> Look at the rest of hw/*.
>> >
>> > I think you mean that a similar assumption is made by lots of
>> > other code. Does not mean it's always a good idea and that
On Thu, Mar 18, 2010 at 09:36:15AM +0100, Juan Quintela wrote:
> searching for how to use a qemu api because from only the
> prototypes it is not clear,
That's the issue right there: if prototype is not enough
we should add documentation.
> and just pick an example, and that one uses
> it in a no
On Thu, Mar 18, 2010 at 09:36:15AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
>
> >> Look at the rest of hw/*.
> >
> > I think you mean that a similar assumption is made by lots of
> > other code. Does not mean it's always a good idea and that
> > we need to force this assumption
"Michael S. Tsirkin" wrote:
>> Look at the rest of hw/*.
>
> I think you mean that a similar assumption is made by lots of
> other code. Does not mean it's always a good idea and that
> we need to force this assumption everywhere.
Principle of Least Surprise. as posted in the other email, rem
On Thu, Mar 18, 2010 at 08:36:26AM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Tue, Mar 16, 2010 at 07:51:16PM +0100, Juan Quintela wrote:
> >> Hi
> >>
> >> This series introduces several virtio cleanups:
> >> - add comment to pci (mst)
> >> - tell virtio about DO_UPCAST
> >
"Michael S. Tsirkin" wrote:
> On Tue, Mar 16, 2010 at 07:51:16PM +0100, Juan Quintela wrote:
>> Hi
>>
>> This series introduces several virtio cleanups:
>> - add comment to pci (mst)
>> - tell virtio about DO_UPCAST
>
> I think we should move away from struct layout assumptions that
> DO_UPCAST e
On Tue, Mar 16, 2010 at 07:51:16PM +0100, Juan Quintela wrote:
> Hi
>
> This series introduces several virtio cleanups:
> - add comment to pci (mst)
> - tell virtio about DO_UPCAST
I think we should move away from struct layout assumptions that
DO_UPCAST enforces, and to use container_of where po
48 matches
Mail list logo
