On Mon, 2011-05-23 at 06:24 +0100, Stefan Hajnoczi wrote:
> On Sat, May 21, 2011 at 2:29 PM, Kevin O'Connor <kevin@xxxxxxxxxxxx> wrote:
> > On Thu, May 19, 2011 at 02:33:52PM +0900, Daniel Castro wrote:
> >> 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?
> >
> > In the general case, no.
> >
> > The ACPI spec does define a mechanism for the OS to inform the BIOS
> > that it is transitioning from "Legacy state" to "Working state" via an
> > SMI. SeaBIOS does have code for this (see src/smm.c), but it doesn't
> > currently do anything interesting. Unfortunately, this is only
> > available for OSs that support ACPI.
> >
> >> 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.
> >
> > Is it required to close the channel? Can opening a new channel
> > implicitly close the old channel (I believe this is what the virtio
> > stuff does)?
>
> There ought to be a way for the guest to reset the device. At least
> in virtio this can be done and allows an in-use device to be reused,
> no matter what state it is in.
There probably ought to be, but currently there isn't :-(
It might be that some existing frontends manage to cope gracefully with
this, but I'm doubtful it will be all of them.
We were hoping to be able to enable this BIOS feature automatically and
transparently to the user/guest OS but if we can't figure out a
clean/sane way to do that we have the fallback option of exposing this
as an option to users, updating the frontend drivers to cope by adding
reset functionality and using the PV emulated device unplug protocol
(which includes a protocol version field) to cause dangerous
combinations of old drivers vs. enabling this new feature to fail.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home