From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53099 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q72XN-0006Ya-2c for qemu-devel@nongnu.org; Tue, 05 Apr 2011 05:27:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q72XL-0007Yi-Mx for qemu-devel@nongnu.org; Tue, 05 Apr 2011 05:27:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q72XL-0007Xo-Bz for qemu-devel@nongnu.org; Tue, 05 Apr 2011 05:26:59 -0400 Date: Tue, 5 Apr 2011 14:56:48 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change Message-ID: <20110405092648.GA28577@amit-x200.redhat.com> References: <4D99C61E.3080600@redhat.com> <4D99C9ED.3020602@codemonkey.ws> <4D99CC74.9070703@redhat.com> <20110405064120.GB2872@amit-x200.redhat.com> <4D9AC940.5000502@redhat.com> <20110405080900.GE2872@amit-x200.redhat.com> <4D9ADA36.8040306@redhat.com> <20110405091203.GC27661@amit-x200.redhat.com> <4D9ADE2A.2020201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9ADE2A.2020201@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Stefan Hajnoczi , Juan Quintela , libvir-list@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Ryan Harper On (Tue) 05 Apr 2011 [12:17:30], Avi Kivity wrote: > On 04/05/2011 12:12 PM, Amit Shah wrote: > >On (Tue) 05 Apr 2011 [12:00:38], Avi Kivity wrote: > >> On 04/05/2011 11:09 AM, Amit Shah wrote: > >> >On (Tue) 05 Apr 2011 [10:48:16], Avi Kivity wrote: > >> >> On 04/05/2011 09:41 AM, Amit Shah wrote: > >> >> >See http://www.spinics.net/lists/linux-scsi/msg51504.html > >> >> > >> >> I see this is quite fresh. What are the plans here? > >> > > >> >We're still discussing where the fix should be, but it certainly is a > >> >kernel bug and should be fixed there, and then applied to stable. > >> > > >> >However, there are other bugs in qemu which will prevent the right > >> >size changes to be visible in the guest (the RFC series I sent out > >> >earlier in this thread need to be applied to QEMU at the least, the > >> >series has grown in my development tree since the time I sent that one > >> >out). So essentially we need to update both, the hypervisor and the > >> >guest to get proper CDROM media change support. > >> > >> Why do we need to update the guest for a qemu bug? What is the qemu bug? > > > >Guest kernel bug: CDROM change event missed, so the the revalidate > >call isn't made, which causes stale data (like disc size) to be used > >on newer media. > > > >qemu bug: We don't handle the GET_EVENT_STATUS_NOTIFICATION command > >from guests (which is a mandatory command acc. to scsi spec) which the > >guest uses to detect CDROM changes. Once this command is implemented, > >QEMU sends the required info the guest needs to detect CDROM changes. > >I have this implemented locally (also sent as RFC PATCH 2/3 in the > >'cdrom bug roundup' thread. > > > >So: even if qemu is updated to handle this command, the guest won't > >work correctly since it misses the event. > > Okay. We aren't responsible for guest kernel bugs, especially those > which apply to real hardware (we should make more effort for virtio > bugs). It's enough that we fix qemu here. > > >> >It also looks like we can't have a workaround in QEMU to get older > >> >guests to work. > >> > >> Older guests? or older hosts? > > > >Older guests (not patched with fix for the bug described above). > > > >Since the guest kernel completely misses the disc change event in the > >path that does the revalidation, there's nothing qemu can do that will > >make such older guests notice disc change. > > > >Also: if only the guest kernel is updated by qemu is not, things still > >won't work since qemu will never send valid information for the > >GET_EVENT_STATUS_NOTIFICATION command. > > > >> >However, a hack in the kernel can be used without any QEMU changes > >> >(revalidate disk on each sr_open() call, irrespective of detecting any > >> >media change). I'm against doing that for upstream, but downstreams > >> >could do that for new guest - old hypervisor compat. > >> > >> Seriously confused. Please use the kernels "host kernel" and "qemu" > >> instead of "hypervisor" which is ambiguous. > > > >OK: this last bit says that forcefully revalidating discs in the guest > >kernel when a guest userspace opens the disc will ensure size changes > >are reflected properly for guest userspace. So in this case, even if > >we're using an older qemu which doesn't implement > >GET_EVENT_STATUS_NOTIFICATION, guest userspace apps will work fine. > > > >This is obviously a hack. > > Yes. Thanks for the clarification. > > (let's see if I really got it - we have a kernel bug that hit both > the guest and the host, plus a qemu bug?) Yes -- but just that we have many more qemu bugs. Our cdrom emulation has a lot of holes when it comes to being spec-compliant. I have a few fixes, Markus is working on some as well. Amit