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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list