[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 13/28] hw/xen: automatically assign device index to block devices
On 27/10/2023 09:45, David Woodhouse wrote: On Fri, 2023-10-27 at 08:30 +0100, Durrant, Paul wrote:+ if (blockdev->props.vdev.type == XEN_BLOCK_VDEV_TYPE_INVALID) { + XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev))); + char fe_path[XENSTORE_ABS_PATH_MAX + 1]; + char *value; + int disk = 0; + unsigned long idx; + + /* Find an unoccupied device name */Not sure this is going to work is it? What happens if 'hda' or 'sda', or 'd0' exists? I think you need to use the core of the code in xen_block_set_vdev() to generate names and search all possible encodings for each disk.Do we care? You're allowed to have *all* of "hda", "sda" and "xvda" at the same time. If a user explicitly provides "sda" and then provides another disk without giving it a name, we're allowed to use "xvda". Maybe sda and xvda can co-exist, but https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xen-vbd-interface.7.pandoc;h=ba0d159dfa7eaf359922583ccd6d2b413acddb13;hb=HEAD#l125says that you'll likely run into trouble if hda exists and you happen to create xvda. Hell, you can also have *separate* backing stores provided as "hda1", "sda1" and "xvda1". I *might* have tolerated a heckle that this function should check for at least the latter of those, but when I was first coding it up I was more inclined to argue "Don't Do That Then". This code is allocating a name automatically so I think the onus is on it not create a needless clash which is likely to have unpredictable results depending on what the guest is. Just avoid any aliasing in the first place and things will be fine. Paul
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |