From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Ideas for PV on SeaBIOS Date: Sat, 21 May 2011 09:39:06 +0200 Message-ID: <4DD76C1A.6030203@redhat.com> References: <1305792117.20907.157.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1305792117.20907.157.camel@zakaz.uk.xensource.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: Ian Campbell Cc: Daniel Castro , Keir Fraser , "seabios@seabios.org" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 05/19/2011 10:01 AM, Ian Campbell wrote: > We had a bit of a brainstorm yesterday and someone suggested that > perhaps qemu could deal with it when it sees the I/O ports for the > emulated device unplug get hit. You could imagine doing the unplug even under an OS that uses INT 13h. PV drivers also aren't forced to do the unplug: RHEL5 guests (up to 5.7 at least) use blacklisting, and the Red Hat PV drivers for Windows use a filter driver because I never got the unplug to work. If SeaBIOS is guaranteed to never reinitialize the callback via, trapping writes to HVM_PARAM_CALLBACK_IRQ with an SMI-like effect sounds like the way to go, as everybody probably agrees at this point. You could also initate the shutdown from dom0, which you could easily do via ACPI even. ;) STORE_PFN and STORE_EVTCHN parameters are usually written only by dom0 (in fact perhaps setting them could be made a privileged operation), which makes them less ideal. Paolo