Re: [Xen-devel] set_phys_to_machine not exported?

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> > +       NO_EMULATE(RESERVE);               /*0x16*/
> > +       NO_EMULATE(RELEASE);               /*0x17*/
> 
> These don't appear to be generated anywhere in the Linux tree, even
> though several drivers implement their handing. Am I then to understand
> that it's Windows which is actually making use of them?

Backup Exec under Windows tries to RESERVE my LTO3 drive and refuses to touch 
it if it can't. I guess if the device reports or is known to support 
RESERVE/RELEASE then it would be expected to be implemented.

> If so, is there a way to know what other commands Linux doesn't use may
> still need enabling in the emulation table for Windows' sake?
> 

This is stretching my memory a bit, but the very first incantation of pvscsi 
was at the per-device level. Then someone mentioned that it would be great to 
be able to map individual LUN's instead of entire devices. This obviously 
requires all sorts of emulation and remapping of commands which I think is 
where the EMULATE stuff came from. I can't quite remember but I suspect there 
might have been some confusion as to what a LUN actually was.

IMHO the per-LUN idea sounds good in theory but would be really hard to 
implement as you'd potentially need to decode and re-encode every single 
reported page of data to adjust the LUN numbers, and probably breaks various 
aspects of the scsi spec (doesn't the spec require that LUN 0 exist?).

So if you are mapping through entire devices I don't know that much really 
needs emulating and we could just uncomment the lot so they just pass straight 
through... I wonder if anyone actually needs the per-lun passthrough and even 
if they think they need it, if it would actually work?

James


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