From mboxrd@z Thu Jan 1 00:00:00 1970 From: Etienne Martineau Subject: Re: pci-assign terminates the guest upon pread() / pwrite() error? Date: Thu, 20 Sep 2012 16:36:42 -0400 Message-ID: <505B7E5A.7050606@gmail.com> References: <505B5218.10009@gmail.com> <1348164984.2320.5.camel@ul30vt.home> <505B6991.5040407@gmail.com> <1348169823.2320.10.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Marcelo Tosatti , kvm To: Alex Williamson Return-path: Received: from mail-vb0-f46.google.com ([209.85.212.46]:54915 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751351Ab2ITUgq (ORCPT ); Thu, 20 Sep 2012 16:36:46 -0400 Received: by vbbff1 with SMTP id ff1so3085587vbb.19 for ; Thu, 20 Sep 2012 13:36:45 -0700 (PDT) In-Reply-To: <1348169823.2320.10.camel@ul30vt.home> Sender: kvm-owner@vger.kernel.org List-ID: On 09/20/2012 03:37 PM, Alex Williamson wrote: > On Thu, 2012-09-20 at 15:08 -0400, Etienne Martineau wrote: >> On 09/20/2012 02:16 PM, Alex Williamson wrote: >>> On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote: >>>> In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read() >>>> result in a hw_error(). Similarly a pwrite() error part of >>>> assigned_dev_pci_write() also result in a hw_error(). >>>> >>>> Would there be a way to avoid terminating the guest for those cases? How >>>> about we deassign the device upon error? >>> >>> By terminating the guest we contain the error vs allowing the guest to >>> continue running with invalid data. De-assigning the device is >>> asynchronous and relies on guest involvement, so damage is potentially >>> already done. Is this a theoretical problem or do you actually have >>> hardware that hits this? Thanks, >>> >>> Alex >>> >> >> This problem is in the context of a Hot-pluggable device assigned to the >> guest. If the guest rd/wr the config space at the same time than the >> device is physically taken out then the guest will terminate with >> hw_error(). >> >> Because this limits the availability of the guest I think we should try >> to recover instead. I don't see what other damage can happen since >> guest's MMIO access to the stale device will go nowhere? > > So you're looking at implementing surprise device removal? There's not > just config space, there's slow bar access and mmap'd spaces to worry > about too. What does going nowhere mean? If it means reads return -1 > and the guest is trying to read the data portion of a packet from the > network or an hba, we've now passed bad data to the guest. Thanks, > > Alex > > > Thanks for your answer; Yes we are doing 'surprise device removal' for assigned device. Note that the problem also exist with standard 'attention button' device removal. The problem is all about fault isolation. Ideally, only the corresponding driver should be affected by this 'surprise device removal'. I think that taking down the guest is too coarse. Think about a 'surprise device removal' on the host. In that case the host is not taken down so why not do the same with the guest? Yes some badness will be latched into the guest but really this not any different that having a mis-behaving device. thanks, Etienne