From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Shelton Subject: Re: non-dom0 disk backend still not working after recent patches Date: Wed, 1 May 2013 09:27:02 -0400 Message-ID: <-8708047380472786305@unknownmsgid> References: <1367339919.3142.597.camel@zakaz.uk.xensource.com> <4592741552091255017@unknownmsgid> <1367395984.3142.610.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1367395984.3142.610.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Eric Shelton List-Id: xen-devel@lists.xenproject.org On May 1, 2013, at 4:13 AM, Ian Campbell wrote: > On Tue, 2013-04-30 at 18:04 +0100, Eric Shelton wrote: >> Will/should xl block-attach make the domU backend disk available to dom0? > > I think so, it might depend a bit on your dom0 kernel. Although whether > you would then be allowed to use it as a guest disk (which I guess is > why you are asking) I'm not sure. > >> Would you expect this to work directly for a PV guest, > > Yes. > >> or am I going >> to have to turn to pygrub (assuming it similarly facilitates storage >> access) or some other mechanism? > > Actually, pygrub is one thing I would expect not to work (precisely > because it needs access to the domain disks in dom0). I'd expect either > explicitly providing the kernel or using pvgrub would work. > > Ian. Thanks again. I got a chance to look into pvgrub a bit more, and I see it essentially has the same issue as non-stubdom hvm. Problems remain in the stubdom code path. Now it dies in xenstore_get_backend_path() in qemu-xen-traditional because bpath corresponds to the correct domU path, but the expected path is under the dom0 path. This is because domid_backend is initialized to 0, and is never changed. There is a comment where it is initialized that essentially identifies this as a todo. My guess is that the backend domain number should be indicated somewhere in the command line for qemu-dm (likely the -disk parameters), and then stored in domid-backend. Does anyone have any comments on the appropriate implementation? I also will note that this will require a change to qemu-xen-traditional. On the other hand, I expect the change to be small, and probably reasonable to roll into 4.3. However, as qemu-cen-traditional appears to be quasi-depricated, I would like to know if such a change would be accepted. A similar change, if not already implemented, would also be needed in qemu-xen for linux-stubdoms. -Eric