Xen devel - Nov 2008 - detecting a ''block-configure'' via xenbus

How should I be detecting a block-configure operation done in Dom0 in a
HVM DomU?

Under Debian Lenny''s Xen 3.2.1, when I execute such a command, Dom0
writes to the backend values ''params'' and
''type'', twice, but doesn''t
update the ''sectors'' value to match the new device, or
initiate a state
change. Given that, the best I can come up with is to watch
''params'',
and initiate the state change in DomU to re-initialise the backend
connection and hopefully get an updated sectors value...

Also, is there a mechanism for detecting a cdrom eject if it is a real
cdrom being emulated?

I''ve been exchanging emails with a guy on the -users list who is using
the GPLPV drivers under XenSource''s product. I''m a little
surprised that
they work, but apparently they fix a few problems he has had with
XenSource''s own Windows PV drivers. My drivers don''t detect
ejecting
CDROM''s though, and I''m wondering if the open source tree even
has a
mechanism for this - either at 3.3 or an earlier version.

Thanks for any info

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 16/11/08 09:02, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> Under Debian Lenny''s Xen 3.2.1, when I execute such a command,
Dom0
> writes to the backend values ''params'' and
''type'', twice, but doesn''t
> update the ''sectors'' value to match the new device, or
initiate a state
> change. Given that, the best I can come up with is to watch
''params'',
> and initiate the state change in DomU to re-initialise the backend
> connection and hopefully get an updated sectors value...
block-configure has only ever worked for CDROM virtual media changes (i.e.,
change ISO file) for HVM guests, via full qemu CDROM drive emulation. It
appears nothing else was ever implemented, so this has no chance of working
without further blkback/blktap changes.

I noticed that the SuSE kernel does have a new blkback source file cdrom.c
which I don''t think has ever been proposed for inclusion in
xen-unstable.
Perhaps that is a protocol extension worth looking at?

 -- Keir
> Also, is there a mechanism for detecting a cdrom eject if it is a real
> cdrom being emulated?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On 16/11/08 09:02, "James Harper"
<james.harper@bendigoit.com.au>
wrote:
> 
> > Under Debian Lenny''s Xen 3.2.1, when I execute such a
command, Dom0
> > writes to the backend values ''params'' and
''type'', twice, but doesn''t
> > update the ''sectors'' value to match the new device,
or initiate a
state
> > change. Given that, the best I can come up with is to watch
''params'',
> > and initiate the state change in DomU to re-initialise the backend
> > connection and hopefully get an updated sectors value...
> 
> block-configure has only ever worked for CDROM virtual media changes
> (i.e.,
> change ISO file) for HVM guests, via full qemu CDROM drive emulation.
It
> appears nothing else was ever implemented, so this has no chance of
> working
> without further blkback/blktap changes.
> 
> I noticed that the SuSE kernel does have a new blkback source file
cdrom.c
> which I don''t think has ever been proposed for inclusion in
xen-unstable.
> Perhaps that is a protocol extension worth looking at?
> 
It reportedly works with the Citrix product, is the protocol definition
itself open? A xenstore-ls shows what looks like some SCSI modepage data
in the tree which I hadn''t seen before too.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 16/11/08 09:19, "James Harper"
<james.harper@bendigoit.com.au> wrote:
>> I noticed that the SuSE kernel does have a new blkback source file
> cdrom.c
>> which I don''t think has ever been proposed for inclusion in
> xen-unstable.
>> Perhaps that is a protocol extension worth looking at?
> 
> It reportedly works with the Citrix product, is the protocol definition
> itself open? A xenstore-ls shows what looks like some SCSI modepage data
> in the tree which I hadn''t seen before too.
I don''t think there''s any particular reason for it to be
closed, and in any
case the interactions via xenstore, and the kernel driver sources, are open
for anyone to take a look at. A lot of Citrix stuff does end up in the
public trees -- it may just be that noone has considered this, or it needs
clean up, or something...

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel