RE: Ideas for PV on SeaBIOS

["James Harper" <james.harper@bendigoit.com.au>]

> 
> Good Day,
> 
> In order to give PV Drivers to SeaBIOS we will need to solve a few
> problems, one is the following:
> Does a booting kernel informs the BIOS that it will leave real mode
> and not use it again? When the booting kernel uses CPU real mode for
> the last time, how can we (Xen or SeaBIOS) know that real mode will no
> longer be used, and hence BIOS calls will not be issued?
> We want upon last real mode usage to leave all Xen PV information in a
> clean state, this means, closing the channel and ring between the
> newly created domain and the host system.
> 
> If you have any ideas please let me know.
> 

You can look at the Linux source code and see what the first thing it
does is. With GPLPV, the first thing I do is set up logging to
/var/log/qemu-dm-<domu name>.log (iowrites which are caught by qemu),
but only under the checked drivers. The next thing is to balloon down
the memory before Windows touches it too much. Then I disable the qemu
devices (iowrites which are caught by qemu). Finally I check the CPUID
for the xen signature (should probably do that first) and then set up
the rights etc.

I think the cheapest way to do it would be to trap the iowrite's and use
that as the trigger to tear down the rings etc, as the iowrites are
already processed in qemu which should be easier to intercept, but the
xen guys would need to comment on if you can guarantee that this is
always done by any reasonably recent version of Linux with PV drivers.
There may well be lots of current installations that pre-date those
iowrite's.

Next I guess you could look for the WriteMSR instruction to copy the
hypercall pages in, or look for an OS querying the CPUID's where the Xen
signatures live, but then the Hyper-V signatures are there too and I
don't know when Windows queries those. Possibly harder to trap as Xen
would either need to signal qemu or SeaBIOS directly that this had
happened.

Alternatively, seeing the HVM_PARAM_CALLBACK_IRQ, HVM_PARAM_STORE_PFN,
and HVM_PARAM_STORE_EVTCHN hypercalls (hvm set op) is the definitive way
to know that the OS is initialising the xenbus interface. SeaBIOS would
need to trap the calls (all three I guess in case they were executed in
an order you didn't expect) before they were executed, which would be
harder as I think qemu never sees it. This early intervention would be
required as you'd need to use xenbus to tear down the interfaces which
is probably asking a bit much.

James