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

[Avi Kivity]

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?)

-- 
error compiling committee.c: too many arguments to function