From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Ideas for PV on SeaBIOS Date: Thu, 19 May 2011 09:20:47 +0100 Message-ID: <20110519082047.GA27118@whitby.uk.xensource.com> References: <4DD4EC2502000078000420F7@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: Content-Disposition: inline In-Reply-To: <4DD4EC2502000078000420F7@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Daniel Castro , "xen-devel@lists.xensource.com" , "seabios@seabios.org" List-Id: xen-devel@lists.xenproject.org At 09:08 +0100 on 19 May (1305796117), Jan Beulich wrote: > How can you be certain an OS won't switch back to real mode even > after an extended period of up-time? Or that such switching back > would affect you (could be calling e.g. the video or PCI BIOS > functions only). You can't, but you could always try to re-establish PV connections if the guest starts making INT13h call again. In any case the existing BIOS has this problem if the PV drivers have turned off the emulated devices. As for how you tidy up cleanly, I can't think of anything better than a sort of virtual SMM, where you register an area of code to be run in a known sane environment and have Xen trigger it based on, e.g. the disable-my-devices ioport write. It's pretty ugly but at least it'd be fairly self-contained compared to having Xen or qemu try to tear down grant-table entries &c. Tim. -- Tim Deegan Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)