[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1.0] virtio: add and use virtio_set_features
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 1.0] virtio: add and use virtio_set_features |
Date: |
Sat, 26 Nov 2011 22:45:17 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Nov 25, 2011 at 09:23:42AM +0100, Paolo Bonzini wrote:
> On 11/24/2011 06:55 PM, Michael S. Tsirkin wrote:
> >> Could some backend make it a hard failure?
> >
> >I don't see how, there's no way to report a failure from
> >an io port write.
>
> You can exit(1), or fall back to a restricted set of features like
> we do for BAD_FEATURE. BAD_FEATURE is a special case of features
> that is not exposed by the host, but requested by the guest.
I donn't think we want to exit on BAD_FEATURE...
> >> If I understand
> >> correctly, this would have prevented the BAD_FEATURE bug too.
> >
> >Which bug?
>
> VIRTIO_F_BAD_FEATURE(30)
> This feature should never be negotiated by the guest; doing so is an
> indication that the guest is faulty. An experimental virtio PCI
> driver contained in Linux version 2.6.25 had this problem, and this
> feature bit can be used to detect it.
Ah, I understand, you mean helping debugging.
OK, but if we add exit() in the future we still do
not need to return a status from this function.
> > what would have prevented it.
>
> exit(1) on unsupported features.
>
> Paolo
This is somewhat problematic, for example this does not flush
out the cache and so might cause data corruption.
Yet I think it would be nice to have a 'safe_exit' functionality
to invoke on a guest bug. Or maybe it's better to stop the VM,
this way the monitor is available and debugging is easier.
--
MST