On Friday 03 July 2015 11:31 AM, David Gibson wrote: > On Thu, Jul 02, 2015 at 07:11:52PM +1000, Alexey Kardashevskiy wrote: >> On 04/02/2015 03:46 PM, David Gibson wrote: >>> On Thu, Apr 02, 2015 at 03:28:11PM +1100, Alexey Kardashevskiy wrote: >>>> On 11/19/2014 04:48 PM, Aravinda Prasad wrote: >>>>> >>>>> >>>>> On Tuesday 11 November 2014 08:54 AM, David Gibson wrote: >>>>> >>>>> [..] >>>>> >>>>>> >>>>>> So, this may not still be possible depending on whether the KVM side >>>>>> of this is already merged, but it occurs to me that there's a simpler >>>>>> way. >>>>>> >>>>>> Rather than mucking about with having to update the hypervisor on the >>>>>> RTAS location, they have qemu copy the code out of RTAS, patch it and >>>>>> copy it back into the vector, you could instead do this: >>>>>> >>>>>> 1. Make KVM instead of immediately delivering a 0x200 for a guest >>>>>> machine check, cause a special exit to qemu. >>>>>> >>>>>> 2. Have the register-nmi RTAS call store the guest side MC handler >>>>>> address in the spapr structure, but perform no actual guest code >>>>>> patching. >>>>>> >>>>>> 3. Allocate the error log buffer independently from the RTAS blob, >>>>>> so qemu always knows where it is. >>>>>> >>>>>> 4. When qemu gets the MC exit condition, instead of going via a >>>>>> patched 0x200 vector, just directly set the guest register state and >>>>>> jump straight into the guest side MC handler. >>>>>> >>>>> >>>>> Before I proceed further I would like to know what others think about >>>>> the approach proposed above (except for step 3 - as per PAPR the error >>>>> log buffer should be part of RTAS blob and hence we cannot have error >>>>> log buffer independent of RTAS blob). >>>>> >>>>> Alex, Alexey, Ben: Any thoughts? >>>> >>>> >>>> Any updates about FWNMI? Thanks >>> >>> Huh.. I'd completely forgotten about this. Aravinda, can you repost >>> your latest work on this? >> >> >> Aravinda disappeared... > > Ok, well someone who cares about FWNMI is going to have to start > sending something, or it won't happen.
I am yet to work on the new approach proposed above. I will start looking into that this week. > -- Regards, Aravinda
