qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	wein@linux.vnet.ibm.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation
Date: Wed, 02 May 2012 13:07:06 +0200	[thread overview]
Message-ID: <4FA1155A.6080400@suse.de> (raw)
In-Reply-To: <4FA1117F.3070908@de.ibm.com>

On 05/02/2012 12:50 PM, Christian Borntraeger wrote:
> On 02/05/12 12:25, Paolo Bonzini wrote:
>> Il 02/05/2012 12:18, Christian Borntraeger ha scritto:
>>> Maybe that really points to the problem that we are trying to solve here.
>>> For a dasd device, there is usually a 4096 byte block size and on the host
>>> these 4096 arereported via getss and getpbsz.
>>> The geometry reported by the device driver is usually 15 head and 12 sectors
>>> per track, but actually means 12 sectors of 4096 bytes size (a track ~ 48k).
>>>
>>> What I want to achieve is that the guest view is identical to the host view
>>> for cyls, heads, secs, and all block sizes.
>> I think what you want is _not_ to have the same view as the host.  What
>> you want is simply to have a default that is consistent with what is
>> common on actual s390 disks.
> Let me put it in another way:
>
> I want to have these values to match the _device_ that we are passing to the guest
> because several tools and the partition detection code for a compatible disk format
> (those that can be accessed by z/OS) needs those values to work properly.
>
> That of course means that the guest view is identical to the host view because both
> views describe a real property of the hardware.
>
> IOW the geometry for dasd devices is not an artifical number, it has some real meaning
> that has a influence on the data structures on the disk.
>
> Thing is, the easiest way of getting the hardware property is to query the host.
>
> Does that make the situation a bit clearer?

Another thing to consider is that there are 2 generic types of disks:

   * SCSI disks
   * DASD disks

Both can be accessed using virtio-blk-s390. The former have the same 
semantics on geometry as what we're used to. They use normal MBRs and 
essentially the geometry doesn't mean too much these days anymore ;). 
However, if possible, I would like to diverge these as little as 
possible from x86 virtio disks.

For DASD disks, the geometry is important, as its disk label is usually 
not MBR, but something s390 specific. That one is different depending on 
the geometry. So here the geometry is very important. The geometry on 
the same disk can also be different, depending on how it's formatted. So 
it's not quite as easy to reconstruct it from the imformation we already 
have. IIUC if we have the logical block size and the information that 
it's a DASD disk, we should be able to guess the geometry though.


Alex

  parent reply	other threads:[~2012-05-02 11:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1335448165-26174-1-git-send-email-borntraeger@de.ibm.com>
     [not found] ` <1335448165-26174-2-git-send-email-borntraeger@de.ibm.com>
     [not found]   ` <4F9AC55F.5000101@redhat.com>
2012-05-02 10:18     ` [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation Christian Borntraeger
2012-05-02 10:25       ` Paolo Bonzini
2012-05-02 10:50         ` Christian Borntraeger
2012-05-02 11:05           ` Paolo Bonzini
2012-05-02 11:07           ` Alexander Graf [this message]
2012-05-02 11:09             ` Paolo Bonzini
2012-05-02 11:10               ` Alexander Graf
2012-05-02 11:23                 ` Paolo Bonzini
     [not found] ` <1335448165-26174-3-git-send-email-borntraeger@de.ibm.com>
     [not found]   ` <4F9AC55D.3000904@redhat.com>
2012-05-02 10:27     ` [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO Christian Borntraeger
2012-05-02 11:09       ` Alexander Graf
2012-05-02 11:26         ` Paolo Bonzini
2012-05-02 11:35           ` Alexander Graf
2012-05-02 11:38             ` Paolo Bonzini
2012-05-02 12:54               ` Alexander Graf
2012-05-02 14:27                 ` Christian Borntraeger
2012-05-02 15:05                   ` Alexander Graf
2012-05-02 18:49                     ` Christian Borntraeger
2012-05-02 15:57                   ` Stefan Weinhuber
2012-05-02 18:39                     ` Alexander Graf
2012-05-02 11:56         ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA1155A.6080400@suse.de \
    --to=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=graalfs@linux.vnet.ibm.com \
    --cc=hch@lst.de \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wein@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).