From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH 5/6] libxl: introduce libxl__alloc_vdev Date: Fri, 30 Mar 2012 16:23:12 +0100 Message-ID: References: <1332856772-30292-5-git-send-email-stefano.stabellini@eu.citrix.com> <20337.63133.683848.208682@mariner.uk.xensource.com> <20341.49280.31751.307404@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20341.49280.31751.307404@mariner.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 Jackson Cc: "xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Fri, 30 Mar 2012, Ian Jackson wrote: > Stefano Stabellini writes ("Re: [PATCH 5/6] libxl: introduce libxl__alloc_vdev"): > > On Tue, 27 Mar 2012, Ian Jackson wrote: > > > Furthermore, for the purpose for which you're using this, you should > > > not start at zero (xvda). You should start at at least 26 (xvdA) and > > > possibly later. That way you are less likely to clash with other > > > statically-allocated vbds. > > > > Another interesting observation but I disagree: why should we expect > > "statically-allocated vbds" below xvdA? How many do you think we are > > going to find? Why 26? I think it is very arbitrary. > > We should just make sure that our allocation policy works well and start > > from 0. > > Your design assumes that the system administrator has not configured, > for themselves, any disks to be exposed to dom0 (eg by a driver > domain). If they have (eg, run "xl block-attach 0 vdev=xvda ...") > then they will expect it to work, and they will expect to be able to > control the device name that this appears as in dom0. Therefore the > namespace of xvd* names in dom0 is not freely available to us as libxl > programmers; we need to avoid trampling all over it. > > Since we need to be able to allocate some vbds dynamically, the right > approach is to decree that some portion of the dom0 vbd space is > reserved for static allocations by the administrator, and that the > remainder is for dynamic allocations by software which picks a free > vbd. Naturally the static space should come first. When you hotplug a new disk on your system, for example a new USB disk to your native Linux box, usually Linux chooses the device name for you. I don't see why this should be any different. The admin is going to call instead: xl block-attach 0 and then checkout dmesg. > > > Of course you can't then using the resulting vdev as a pathname in > > > /dev/ but that's nonportable anyway; different guest OSs (and here we > > > are playing the role of the guest) may have different conventions. > > > You need a separate function to convert vdev numbers (as returned from > > > _disk_dev_number) to pathnames in /dev. > > > > This is a good point and the key issue here. > > > > The frontend is actually free to choose whatever name it wants for the > > device it is going to create from the dev number. > > I don't think that is true. On each individual guest platform, the > relationship between vbd numbers (the actual interface between > frontend and backend), and whatever that guest has for device names, > needs to be statically defined. I disagree: when we introduced docs/txt/misc/vbd-interface.txt we never specified what names the guest kernel is allowed to choose for a particular vbd encoding. See the following quote: "The Xen interface does not specify what name a device should have in the guest (nor what major/minor device number it should have in the guest, if the guest has such a concept)." > > So I think that the best thing we can do is rely on it to find out the > > device name, either doing: > > > > [1] xvd(a + i) -> libxl__device_disk_dev_number -> xs_read > > This is not correct, because the device name in the guest is not > written to xenstore anywhere. It is private to the guest. > > (In this case the "guest" is actually dom0, but the point stands.) > > > or reading the "dev" node under the xenstore backend path, that is > > generated using the same libxl function (this is what I am doing now). > > I fail to see why one of these two approaches would be better than the > > other, but if you think that [1] is the best, I can change my code. > > Again, you are confusing the virtual name given in the domain config > file with the actual device name in the guest's /dev, which may not be > the same. What I find confusing is that before you say that "the relationship between vbd numbers and whatever that guest has for device names needs to be statically defined", but then you say that "the device name in the guest is not written to xenstore anywhere. It is private to the guest." In any case that was a conscious decision: considering that we have no way to know the device name in the guest (see above quote), the best thing we can do is guessing. The best guess we can have is using the mapping implemented in libxl__device_disk_dev_number. Maybe we can slightly improve the situation moving libxl__alloc_vdev to an OS specific file so that we can have a Linux and a BSD implementation. Both are going to be "guessing", in particular the Linux version is just going to use libxl__device_disk_dev_number, but the BSD version might want to do something different.