On Thu, Apr 24, 2014 at 12:43:56PM +0200, Kevin Wolf wrote: > Am 24.04.2014 um 09:55 hat Michael S. Tsirkin geschrieben: > > On Thu, Apr 24, 2014 at 09:15:25AM +0200, Markus Armbruster wrote: > > > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > > > > > On Wed, Apr 23, 2014 at 11:22:51AM +0800, Fam Zheng wrote: > > > >> This series is a step towards getting rid of such code, > > > > > > > > Sure, incremental patches are good. At this point I think it's > > > > a good idea to clearly mark this as RFC - I don't think we should yet > > > > merge > > > > this upstream until the solution is a bit more complete. > > > > > > > > Changing virtio is the easy part though, so I'm not sure it's a good > > > > idea to start there. > > > > > > Does this series hinder work on the harder parts in any way? Does it > > > pick a specific solution that may not work for the harder parts? > > > > > > If not, then I can't see what keeping it out of tree can buy us. > > > > Less code churn. It's more code apparently for no real benefit > > since buggy drivers will still abort qemu. > > Depends on what bugs the driver has. > > Not fixing bugs because there are still other bugs that can crash qemu > isn't productive. If we went this way consistently, we would reject any > bug fix unless the commit message contains a mathematical proof that all > of qemu is correct now. We could stop development right now. > > This is an easy bug to fix, we have the patches, so let's just fix it. > The solution won't become any better by waiting for independent fixes. > > > Making nested virt work well is a big project, I'd like to see some > > progress on the hard parts before trying to address easy corner cases > > like this one. > > Addressing the easy parts doesn't make the hard parts any harder. > > > > >> Regarding the malicious guest, protecting D.O.S. attack is also > > > >> valuable, isn't > > > >> it? > > > >> > > > >> Thanks, > > > >> Fam > > > > > > > > Guest denying itself a service? I'm not sure why it's valuable. > > > > > > If I remember correctly, the DOS involved passthrough of a virtual > > > device to a nested guest or something like that. > > > Guest killing itself > > > is unexciting, nested guest killing its host qualifies as DOS. I guess > > > our current answer to that is "don't do that then". > > > > Yes. virtio doesn't support that for a variety of other reasons, > > one of which is that it doesn't go through an mmu. > > Now, before someone sends a trivial patch converting it to > > mmu aware calls, that's not yet possible without teaching vhost > > and dataplane about MMU. > > Nested virt is really just one example for a userspace virtio driver. > Userspace shouldn't be able to kill the whole guest. > > Kevin
Without an MMIO this is fundamentally unavoidable.
