Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Wed, Apr 20, 2016 at 5:30 PM, Paul Durrant <Paul.Durrant@xxxxxxxxxx> wrote:
>> In any case, is it really not the case that the devicemodels on the
>> far side have to re-register which IO ranges they're interested in?
>> Shouldn't the devicemodel on the far side re-register the pfns it
>> wants to watch as well?  That again seems like the most robust
>> solution, rather than assuming that the pfns you expect to have been
>> marked are already marked.  To do otherwise risks bugs where 1) pages
>> you think were being watched aren't 2) pages being watched that you
>> don't care about (and you don't think to un-watch them because you
>> didn't think you'd watched them in the first place).
>>
>
> That sounds a little inefficient when there could be thousands of pages in 
> play. If the p2m types were faithfully reproduced in the receiving domain 
> then the new incarnation of the emulator just needs to claim the type rather 
> than making thousands of set-mem-type hypercalls as well. I agree that the 
> information would need to be transferred though, otherwise the new 
> incarnation wouldn't be able reset the page types when it was done with them.

The emulator could presumably go through and re-shadow the GPTs as
they were used, rather than all at once, right?

I still think that flushing all types on disconnect and having the
ioreq server on the far side re-protect things as it wants to is a
more robust solution.  But ultimately you're probably going to be the
one who's going to have to deal with any bugs related to this, so I'd
leave it between you and Yu Zhang.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel