blkfront/back and sector size of 2048 with CDROM's

blkfront/back and sector size of 2048 with CDROM's

[James Harper]

It looks like mounting a physical CDROM under the windows gpl pv drivers
doesn't work, and I suspect that the problem is because the CDROM uses a
sector size of 2048 instead of 512.

Do the pages passed between the front and backend scale to using
different sector sizes, or do I have to do some magic to fudge them back
to 512?

Thanks

James

Re: blkfront/back and sector size of 2048 with CDROM's

[Samuel Thibault]

James Harper, le Tue 05 Feb 2008 11:09:42 +1100, a écrit :
> Do the pages passed between the front and backend scale to using
> different sector sizes,

The backend decides which sector size to be used, so

> or do I have to do some magic to fudge them back to 512?

Yes.

Samuel

Re: blkfront/back and sector size of 2048 with CDROM's

[Keir Fraser]

On 5/2/08 00:09, "James Harper" <james.harper@bendigoit.com.au> wrote:

> It looks like mounting a physical CDROM under the windows gpl pv drivers
> doesn't work, and I suspect that the problem is because the CDROM uses a
> sector size of 2048 instead of 512.
> 
> Do the pages passed between the front and backend scale to using
> different sector sizes, or do I have to do some magic to fudge them back
> to 512?

The 'sectors' referenced in blkif requests are always 512 bytes. So if you
read 'sector-size' of 2048 from xenstore during blkif setup, that means that
the #sector alignments and sizes you send in requests must be multiples of
4.

 -- Keir

RE: blkfront/back and sector size of 2048 with CDROM's

[James Harper]

> The 'sectors' referenced in blkif requests are always 512 bytes. So if
you
> read 'sector-size' of 2048 from xenstore during blkif setup, that
means
> that
> the #sector alignments and sizes you send in requests must be
multiples of
> 4.

Okay... a forinstance...

I give windows a sector size of 2048 based on what I have read from
xenstore. Windows isssues a read request for sector 1 (byte offset
2048), and a length of 1 sector.

My read buffer is aligned at 1024 bytes into the page, so in the blkif
request I set nr_segments = 1, sector_number = 4 (1 * (2048 / 512)), and
in the first (and only) segment, first_sect = 2 and last_sect = 6.

Does that sound right?

Thanks

James

Re: blkfront/back and sector size of 2048 with CDROM's

[Keir Fraser]

On 5/2/08 08:52, "James Harper" <james.harper@bendigoit.com.au> wrote:

> Okay... a forinstance...
> 
> I give windows a sector size of 2048 based on what I have read from
> xenstore. Windows isssues a read request for sector 1 (byte offset
> 2048), and a length of 1 sector.
> 
> My read buffer is aligned at 1024 bytes into the page, so in the blkif
> request I set nr_segments = 1, sector_number = 4 (1 * (2048 / 512)), and
> in the first (and only) segment, first_sect = 2 and last_sect = 6.
> 
> Does that sound right?

Yes, except that last_sect = 5, because it's an inclusive range.

I'm pretty sure you can DMA to/from unaligned buffers (e.g., in this case
non-2kB aligned). Certainly blkback doesn't appear to check for it, so
presumably we found it works!

 -- Keir

RE: blkfront/back and sector size of 2048 with CDROM's

[James Harper]

> Yes, except that last_sect = 5, because it's an inclusive range.

Yes. :)

> I'm pretty sure you can DMA to/from unaligned buffers (e.g., in this
case
> non-2kB aligned). Certainly blkback doesn't appear to check for it, so
> presumably we found it works!

My buffers are always page aligned anyway. I have no control over the
buffer alignment that windows gives me, so I have to copy the data back
and forth. In a previous version I would check for buffer alignment
first (windows almost always gives you buffers aligned to a page
boundry), but the windows scsi controller interface is really messed
up... you are always called at a really high irq level, and the routines
for mapping buffers to pfn's are not available in that situation.

James