Andreas Färber writes:
> Am 07.03.2013 17:44, schrieb Anthony Liguori:
>> Andreas Färber writes:
>>
>>> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
> It's a bug in both virtio-ccw that features=0 when get_features is
> called. You can also tell this with:
>
> [10:02 AM]
"Michael S. Tsirkin" writes:
> On Thu, Mar 07, 2013 at 10:44:18AM -0600, Anthony Liguori wrote:
>> Andreas Färber writes:
>>
>> > Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>> >>> It's a bug in both virtio-ccw that features=0 when get_features is
>> >>> called. You can also tell this
Am 07.03.2013 17:44, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
It's a bug in both virtio-ccw that features=0 when get_features is
called. You can also tell this with:
[10:02 AM] anthony@titi:~/git/qemu/hw/s390x$
On Thu, Mar 07, 2013 at 10:44:18AM -0600, Anthony Liguori wrote:
> Andreas Färber writes:
>
> > Am 07.03.2013 17:27, schrieb Christian Borntraeger:
> >>> It's a bug in both virtio-ccw that features=0 when get_features is
> >>> called. You can also tell this with:
> >>>
> >>> [10:02 AM] anthony@t
Andreas Färber writes:
> Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>>> It's a bug in both virtio-ccw that features=0 when get_features is
>>> called. You can also tell this with:
>>>
>>> [10:02 AM] anthony@titi:~/git/qemu/hw/s390x$ grep
>>> DEFINE_VIRTIO_NET_FEATURES *
>>> virtio-ccw.
Christian Borntraeger writes:
>> You're misreading how this works.
>>
>> Host features are set based on command line arguments. This is
>> advertised to the guest. The vdev->get_config() call then sanitizes
>> features. For instance, look at:
>>
>> static uint32_t virtio_net_get_features(Vir
On 07.03.2013, at 17:27, Christian Borntraeger wrote:
>> You're misreading how this works.
>>
>> Host features are set based on command line arguments. This is
>> advertised to the guest. The vdev->get_config() call then sanitizes
>> features. For instance, look at:
>>
>> static uint32_t vir
Am 07.03.2013 17:27, schrieb Christian Borntraeger:
>> It's a bug in both virtio-ccw that features=0 when get_features is
>> called. You can also tell this with:
>>
>> [10:02 AM] anthony@titi:~/git/qemu/hw/s390x$ grep DEFINE_VIRTIO_NET_FEATURES
>> *
>> virtio-ccw.c:DEFINE_VIRTIO_NET_FEATURES(
> You're misreading how this works.
>
> Host features are set based on command line arguments. This is
> advertised to the guest. The vdev->get_config() call then sanitizes
> features. For instance, look at:
>
> static uint32_t virtio_net_get_features(VirtIODevice *vdev, uint32_t features)
> {
Christian Borntraeger writes:
> On 05/03/13 17:48, Alexander Graf wrote:
>> On 02/06/2013 12:47 AM, Jesse Larrew wrote:
>>> Currently, the config size for virtio devices is hard coded. When a new
>>> feature is added that changes the config size, drivers that assume a static
>>> config size will
Ping.
Anthony, Jesse,
how is this supposed to work?
Christian
On 05/03/13 18:03, Christian Borntraeger wrote:
> On 05/03/13 17:48, Alexander Graf wrote:
>> On 02/06/2013 12:47 AM, Jesse Larrew wrote:
>>> Currently, the config size for virtio devices is hard coded. When a new
>>> feature is added
On 02/06/2013 12:47 AM, Jesse Larrew wrote:
Currently, the config size for virtio devices is hard coded. When a new
feature is added that changes the config size, drivers that assume a static
config size will break. For purposes of backward compatibility, there needs
to be a way to inform drivers
On 05/03/13 17:48, Alexander Graf wrote:
> On 02/06/2013 12:47 AM, Jesse Larrew wrote:
>> Currently, the config size for virtio devices is hard coded. When a new
>> feature is added that changes the config size, drivers that assume a static
>> config size will break. For purposes of backward compat
On 02/06/2013 12:47 AM, Jesse Larrew wrote:
Currently, the config size for virtio devices is hard coded. When a new
feature is added that changes the config size, drivers that assume a static
config size will break. For purposes of backward compatibility, there needs
to be a way to inform drivers
"Michael S. Tsirkin" writes:
> On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
>> Currently, the config size for virtio devices is hard coded. When a new
>> feature is added that changes the config size, drivers that assume a static
>> config size will break. For purposes of backwar
On Thu, Feb 7, 2013 at 4:55 PM, Anthony Liguori wrote:
> Stefan Hajnoczi writes:
>
>> On Thu, Feb 7, 2013 at 3:43 PM, Laszlo Ersek wrote:
>>> Instead, what about
>>>
>>> #define endof(container, field) \
>>> (offsetof(container, field) + sizeof ((container *)0)->field)
>>
>> As mentioned in
On Thu, Feb 07, 2013 at 03:15:42PM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Feb 07, 2013 at 11:46:55AM -0600, Anthony Liguori wrote:
> >
> > So why do we add extra code who's sole effect is breaking old
> > windows drivers?
>
> A little dramatic, no?
>
> > I li
"Michael S. Tsirkin" writes:
> On Thu, Feb 07, 2013 at 11:46:55AM -0600, Anthony Liguori wrote:
>
> So why do we add extra code who's sole effect is breaking old
> windows drivers?
A little dramatic, no?
> I like the idea but why add code for status and mac features?
Because it's correct and t
On Thu, Feb 07, 2013 at 11:46:55AM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Feb 07, 2013 at 09:45:54AM -0600, Anthony Liguori wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> This is about bug-for-bug compatibility with older QEMU.
> >
> > Sorry, with which v
Stefan Hajnoczi writes:
> On Thu, Feb 7, 2013 at 3:43 PM, Laszlo Ersek wrote:
>> Instead, what about
>>
>> #define endof(container, field) \
>> (offsetof(container, field) + sizeof ((container *)0)->field)
>
> As mentioned in my reply, I think endof() isn't necessary.
>
> Just use offsetof()
Laszlo Ersek writes:
> On 02/07/13 09:55, Michael S. Tsirkin wrote:
>> On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
>>> Currently, the config size for virtio devices is hard coded. When a new
>>> feature is added that changes the config size, drivers that assume a static
>>> conf
"Michael S. Tsirkin" writes:
> On Thu, Feb 07, 2013 at 09:45:54AM -0600, Anthony Liguori wrote:
>> "Michael S. Tsirkin" writes:
>>
>> This is about bug-for-bug compatibility with older QEMU.
>
> Sorry, with which version?
>
> It looks like if I run qemu 1.3 with .status=off
> windows drivers wo
On Thu, Feb 07, 2013 at 04:22:45PM +0100, Stefan Hajnoczi wrote:
> On Thu, Feb 7, 2013 at 3:43 PM, Laszlo Ersek wrote:
> > Instead, what about
> >
> > #define endof(container, field) \
> > (offsetof(container, field) + sizeof ((container *)0)->field)
>
> As mentioned in my reply, I think endo
On Thu, Feb 07, 2013 at 05:56:16PM +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 07, 2013 at 09:45:54AM -0600, Anthony Liguori wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
> > >> Currently, the config size for virtio devices is h
On Thu, Feb 07, 2013 at 09:45:54AM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
> >> Currently, the config size for virtio devices is hard coded. When a new
> >> feature is added that changes the config size, driv
On 02/07/13 16:22, Stefan Hajnoczi wrote:
> On Thu, Feb 7, 2013 at 3:43 PM, Laszlo Ersek wrote:
>> Instead, what about
>>
>> #define endof(container, field) \
>> (offsetof(container, field) + sizeof ((container *)0)->field)
>
> As mentioned in my reply, I think endof() isn't necessary.
>
> J
On 02/07/13 15:43, Laszlo Ersek wrote:
> On 02/07/13 09:55, Michael S. Tsirkin wrote:
>> On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
>>> +#define endof(container, field) \
>>> +((intptr_t)(&(((container *)0)->field)+1))
>>
> Furthermore, taking the pointer to "one past" &fie
On Thu, Feb 07, 2013 at 03:43:51PM +0100, Laszlo Ersek wrote:
> #define endof(container, field) \
> (offsetof(container, field) + sizeof ((container *)0)->field)
Indeed, this looks cleaner.
On Thu, Feb 7, 2013 at 3:43 PM, Laszlo Ersek wrote:
> Instead, what about
>
> #define endof(container, field) \
> (offsetof(container, field) + sizeof ((container *)0)->field)
As mentioned in my reply, I think endof() isn't necessary.
Just use offsetof() the *next* field or sizeof() the enti
On 02/07/13 09:55, Michael S. Tsirkin wrote:
> On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
>> Currently, the config size for virtio devices is hard coded. When a new
>> feature is added that changes the config size, drivers that assume a static
>> config size will break. For purpo
On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index f1c2884..8f521b3 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -73,8 +73,31 @@ typedef struct VirtIONet
> int multiqueue;
> uint16_t max_queues;
> uint
On Tue, Feb 05, 2013 at 05:47:16PM -0600, Jesse Larrew wrote:
> Currently, the config size for virtio devices is hard coded. When a new
> feature is added that changes the config size, drivers that assume a static
> config size will break. For purposes of backward compatibility, there needs
> to be
Currently, the config size for virtio devices is hard coded. When a new
feature is added that changes the config size, drivers that assume a static
config size will break. For purposes of backward compatibility, there needs
to be a way to inform drivers of the config size needed to accommodate the
On 02/05/2013 03:48 PM, Jesse Larrew wrote:
> Currently, the config size for virtio devices is hard coded. When a new
> feature is added that changes the config size, drivers that assume a static
> config size will break. For purposes of backward compatability, there needs
s/compatability/compatib
Currently, the config size for virtio devices is hard coded. When a new
feature is added that changes the config size, drivers that assume a static
config size will break. For purposes of backward compatability, there needs
to be a way to inform drivers of the config size needed to accomodate the
s
35 matches
Mail list logo