Re: [libvirt] [Qemu-devel] [PATCH v2 3/3] raw-posix: Re-open host CD-ROM after media change
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.
>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.
Amit