On Fri, 2019-06-21 at 10:40 +0200, Gerd Hoffmann wrote:
Hi,
Our downstream patch for not initialising NVMe controllers if we aren't going to boot from them, makes its decision based on the priority.
What is the state of that patch btw?
It's on my "technical debt that I want to kill so we're using a pristine upstream again" list. I'll take a look after I've fixed the final quirks and got CSM boots working seamlessly again.
I remember it being posted a while back, suggestion was to make it generic (skip init for everything which has a priority higher than "HALT", not only nvm), but the discussion went silent quickly and IIRC there never was a v2 of that patch ...
If we do that, then those drives won't be available to INT13h at all. We'd be saying that just because we don't want to *boot* from them, DOS can't see them at all.
Would we assign INT13h drive numbers to them and initialise them on demand? I don't think that can work because we don't even know if an ATA drive is present, don't know how many NVMe namespaces are present, so couldn't assign numbers accordingly.
Perhaps the first INT13h access to a drive that doesn't exist (0x81 normally?) would trigger *all* pending drive probes to happen? Can we even do them that late?
Or do we make it an option — at build time or through fw_cfg or something else, to just *not* initialise those drives at all because we know we're not booting DOS today?