On 05/17/2012 05:57 PM, Alexander Graf wrote:
On 03.05.2012, at 15:34, Alexander Graf wrote:
On 03.05.2012, at 14:32, Anthony Liguori wrote:
On 05/03/2012 04:07 AM, Alexander Graf wrote:
On 03.05.2012, at 11:05, Paolo Bonzini wrote:
The usual old fix was to not even compile them in. W
On 03.05.2012, at 15:34, Alexander Graf wrote:
>
> On 03.05.2012, at 14:32, Anthony Liguori wrote:
>
>> On 05/03/2012 04:07 AM, Alexander Graf wrote:
>>>
>>> On 03.05.2012, at 11:05, Paolo Bonzini wrote:
>>>
>> The usual old fix was to not even compile them in. Why are they in
>
On 03.05.2012, at 14:32, Anthony Liguori wrote:
> On 05/03/2012 04:07 AM, Alexander Graf wrote:
>>
>> On 03.05.2012, at 11:05, Paolo Bonzini wrote:
>>
>>>
> The usual old fix was to not even compile them in. Why are they in
> the alias list in the s390 build now?
Because the
On 05/03/2012 04:07 AM, Alexander Graf wrote:
On 03.05.2012, at 11:05, Paolo Bonzini wrote:
The usual old fix was to not even compile them in. Why are they in
the alias list in the s390 build now?
Because the alias list is in target-independent code.
The old fix was brittle anyway, it dep
> > Uhm, Christian fix would have the same problem actually if
> > virtio-*-pci were to be moved in libhw. IIRC I proposed the
> > same change on review and Anthony nacked it on these grounds.
> > You could move the alias list to target-dependent code, though.
>
> Can't we just make the virtio-*
On 03.05.2012, at 11:05, Paolo Bonzini wrote:
>
>>> The usual old fix was to not even compile them in. Why are they in
>>> the alias list in the s390 build now?
>>
>> Because the alias list is in target-independent code.
>>
>> The old fix was brittle anyway, it dependent on the fact that
>> vi
> > The usual old fix was to not even compile them in. Why are they in
> > the alias list in the s390 build now?
>
> Because the alias list is in target-independent code.
>
> The old fix was brittle anyway, it dependent on the fact that
> virtio-blk-pci was not part of libhw. A similar trick br
> The usual old fix was to not even compile them in. Why are they in
> the alias list in the s390 build now?
Because the alias list is in target-independent code.
The old fix was brittle anyway, it dependent on the fact that
virtio-blk-pci was not part of libhw. A similar trick broke for
cirrus
On 03.05.2012, at 10:53, Christian Borntraeger wrote:
> On 03/05/12 10:49, Alexander Graf wrote:
>>
>> On 03.05.2012, at 10:47, Christian Borntraeger wrote:
>>
>>> When qemu is called with -device virtio-serial/blk/net on s390, this alias
>>> is translated to virtio-serial/blk/net-pci instead o
On 03/05/12 10:49, Alexander Graf wrote:
>
> On 03.05.2012, at 10:47, Christian Borntraeger wrote:
>
>> When qemu is called with -device virtio-serial/blk/net on s390, this alias
>> is translated to virtio-serial/blk/net-pci instead of s390, since these
>> drivers are first in the alias table.
>>
On 03.05.2012, at 10:47, Christian Borntraeger wrote:
> When qemu is called with -device virtio-serial/blk/net on s390, this alias
> is translated to virtio-serial/blk/net-pci instead of s390, since these
> drivers are first in the alias table.
> Let the core code check if the driver exist, if no
When qemu is called with -device virtio-serial/blk/net on s390, this alias
is translated to virtio-serial/blk/net-pci instead of s390, since these
drivers are first in the alias table.
Let the core code check if the driver exist, if not lets search further.
This fixes errors like:
qemu-kvm: -devic
12 matches
Mail list logo
