[libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
Amit Shah
amit.shah at redhat.com
Tue Apr 5 09:26:48 UTC 2011
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
More information about the libvir-list
mailing list