From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [PATCH 3/3] xen-blkfront: Fix minor offset calculation for emulated IDE disks Date: Fri, 15 Jul 2011 12:41:23 +0200 Message-ID: <4E201953.4070206@canonical.com> References: <4E1EEEA1.9050102@canonical.com> <1310650247-7366-1-git-send-email-stefan.bader@canonical.com> <4E1FDCD8.6070002@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 15.07.2011 12:20, Stefano Stabellini wrote: > On Fri, 15 Jul 2011, Stefan Bader wrote: >> On 14.07.2011 19:34, Stefano Stabellini wrote: >>> On Thu, 14 Jul 2011, Stefan Bader wrote: >>>> Before this a block device defined as hda1 in the configuration files >>>> would be mapped to hda, as well as hda2. >>>> >>> >>> Don't you mean xvda and xvda2? >>> >> Bah, yes, you are right. I had a "hda1" in a PVM guests definition and within >> the guest it had become "xvda". Basically it seems that the current code would >> map any minor number between 0-63 to 0. > > That would be correct because hda1 is not allowed, the closest thing to > a valid configuration would be hda and therefore xvda. > I see. So sort of fixing up when there is an invalid HVM configuration. > >>> Besides hda1 doesn't mean anything for an HVM guest, it is not an >>> allowed disk configuration. >>> It is also a bug in the toolstack that propagates such nonsense to >>> xenstore so I would rather fix xend and/or libxenlight. >>> >> Which seems actually to be something that could be intentional for HVM guests. >> As you say, "hdaX" does make no sense there... Unfortunately this is shared for >> PVM and HVM. So my change may make sense with the first but not the latter... :( > > I see. The source of the problem is ancient disk configuration lines in > PV config files: like Ian wrote before, people should be using xvd* only > in PV guests config file, rather than hd* or sd*... > I think the best thing to do here would be to catch the error at the > toolstack level. In that case it was not even a real use-case. I was just trying to see what happens. Though I assume if you _can_ do it, there _will_ be someone doing so... Sounds like both cases would be candidates for the toolstack. But for the kernel patch I made, there is no reason and it should be ignored. Breaking one case for another is not that much of use.