[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support



On Tue, 2013-02-19 at 10:51 +0000, David Woodhouse wrote:
> On Tue, 2013-02-19 at 10:20 +0000, Ian Campbell wrote:
> > I expect there will be some rough edges like the NV variable thing -- I
> > have a feeling these will have a lot in common with qemu/KVM, since they
> > would tend to interact with the "platform" (provided by qemu-dm under
> > Xen) rather than processor or memory virt etc.
> 
> Well, it's mostly just storing text strings describing which device/path
> to boot from. So hopefully if the flash storage itself is OK for Xen,
> the rest should just work.

Ack.

> > For the most part the I reckon the Xen specific things will be resync
> > with a recent upstream and fixup the Xen build system integration, stuff
> > like that. 
> 
> Current upstream OVMF works, AFAICT. Although as I said, I haven't even
> tried booting an OS.
> 
> One thing I obviously *also* haven't tested, therefore, is *rebooting*.,
> We've discovered a KVM bug on older CPUs without 'unrestricted guest'
> mode, where after a reset it actually runs code from 0xffff0 and not
> 0xfffffff0. With the former being SeaBIOS-CSM, and the latter being the
> OVMF startup code that we *should* be running, that's kind of a problem.
> 
> If you have a similar bug, please go and fix it so I never have to
> know :)

I've not heard of such a thing, but I've been half following the thread
and it sounds a bit, shall we say, subtle ;-)

Under Xen when qemu gets a reset event (via I/O writes or whatever) it
ends up with the toolstack actually destroying and recreating the
domain, so I think the issue you are thinking of doesn't come up.

> > We'd like to see PV I/O drivers at some point but that's a separate
> > project in its own right I think.
> 
> If you have an option ROM for them, that might not be a high priority. I
> think OVMF can thunk into INT 13h for disk access.

We don't have an option ROM, but that might be an interesting way to
approach things, although there are issues with teardown before the OS
comes along which endbootservices solves nicely for us.

> > > And on the subject of the NV storage... does -pflash work on qemu-xen,
> > > as long as we're not actually running *code* from the device and we're
> > > only using it for data storage?
> > 
> > I'm not sure, I've CC'd Anthony & Stefano. Assuming the Xen machine type
> > in Qemu wires it up then I don't know why it shouldn't work and if we
> > don't wire it up I don't see why we couldn't.
> 
> Qemu does but not in KVM mode, because it can't *execute* from a region
> and also catch writes to properly emulate flash. But for a flash device
> that we *don't* execute from, because it's only used for NV storage and
> not the firmware itself, that restriction isn't important. So I'll need
> to fix that.

Maybe it would be useful to emulate a dumb NV RAM region, as opposed to
a full flash emulation?

> > Hvmloader might need to be tweaked to setup the e820 correctly and
> > perhaps the some table or other would need to refer to it also?
> 
> Right. Haven't quite worked out how it would be 'found' by the firmware
> yet. I was going to suggest making the address available via fw_cfg...
> but you don't implement that.

There's a little protocol between HVMloader and SeaBIOS which
passes the tables across, see src/xen.c struct xen_seabios_info. Perhaps
HVMloader+OVMF should be (or is?) using the same (or similar). Either
way it should be extensible to cover this new info. The other option is
an HVM_PARAM, which is Xen specific, but pretty simple.

Ian.
-- 
Ian Campbell
Current Noise: Old Man's Child - The Flames Of Deceit

Did I SELL OUT yet??


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.