[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 22.06.16 at 12:15, <george.dunlap@xxxxxxxxxx> wrote:
> On 22/06/16 11:10, Jan Beulich wrote:
>>>>> On 22.06.16 at 11:47, <george.dunlap@xxxxxxxxxx> wrote:
>>> So you're afraid of this sequence of events?
>>> 1) Server A de-registered, triggering a ioreq_server -> ram_rw type change
>>> 2) gfn N is marked as misconfigured
>>> 3) Server B registers and marks gfn N as ioreq_server
>>> 4) When N is accessed, the misconfiguration is resolved incorrectly to
>>> ram_rw
>>>
>>> But that can't happen, because misconfigured entries are resolved before
>>> setting a p2m entry; so at step 3, gfn N will be first set to
>>> (non-misconfigured) ram_rw, then changed to (non-misconfigured)
>>> ioreq_server.
>>>
>>> Or is there another sequence of events that I'm missing?
>> 
>> 1) Server A marks GFN Y as ioreq_server
>> 2) Server A de-registered, triggering a ioreq_server -> ram_rw type
>>    change
>> 3) Server B registers and gfn Y still didn't become ram_rw again (as
>>    the misconfiguration didn't trickle down the tree far enough)
> 
> There are some missing steps here.  Gfn Y is still misconfigured, right?
>  What will happen when the misconfiguration is resolved?  Will it not
> become ram_rw?  If not, what would it change to and why?

Oh, right, of course.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.