On Tue 11/20/07 at 21:25 PM, gdamore at sun.com wrote: > Hmm... I wonder if paravirtualization would work better with something > like my blk2scsa framework (see PSARC 2007/654). Alternatively, maybe > a separate block driver rather than modifying cmdk?
I took a quick look at that case, but it doesn't seem to address the specific issue this was meant to solve. Our decision to modify cmdk was driven by our desire to be able drop these PV drivers onto an existing domain with the least amount of fuss and risk possible. We also wanted to be able to remove the drivers without disabling the domain. When we install an HVM domU without the PV drivers, Solaris believes it is installing to a physical ata device. Thus, the 'cmdk' device name gets hardcoded into the bootpath for that domain. Replacing the cmdk driver with one that is PV-aware allows us to slot the PV disk driver in place, without modifying any delicate files such as /etc/path_to_inst or /boot/solaris/bootenv.rc. It also lets us remove the driver in the future without causing any damage. The old 'metal' driver simply takes over on the next boot. > The idea that we have to touch each driver that needs to support > paravirtualization seems kind of clumsy to me. A lot of the complexity > in extant drivers is to deal with various hardware bugs and workarounds, > and I fear that this approach just further complicates already complex > drivers, and maybe also robs PV drivers of some their performance as well? It's really only the disk device that runs into this problem. This is the only device that simply can't change its name, type, or location. If the path to the boot device isn't _exactly_ the same through the life of the domain, you're dead. Changing the name or type of a NIC is more awkward than one would hope, but it can be done without reinstalling the domain. > But it sounds, from the materials below, like maybe for cmdk's specific > case this isn't too bad, and there maybe upgrade issues that are avoided > by this approach? Yes, exactly. Nils
