On Fri, 2019-06-21 at 10:40 +0200, Gerd Hoffmann wrote:
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?