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
