Re: [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change

[Amit Shah]

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