On Wed, Nov 19, 2014 at 11:32:56AM +0100, Alexander Graf wrote: > > > > > Am 19.11.2014 um 06:48 schrieb Aravinda Prasad > > <aravi...@linux.vnet.ibm.com>: > > > > > > > > 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? > > If in doubt, stick to PAPR please.
Apart from (3), which was a misunderstanding on my part, this doesn't diverge from PAPR - it's just a question of how we're implementing the PAPR behaviour. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
pgpo3TEoR23sA.pgp
Description: PGP signature