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

Re: [Xen-devel] shadow OOS and fast path are incompatible


  • To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
  • From: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
  • Date: Fri, 3 Jul 2009 11:11:07 +0200
  • Cc: Frank van der Linden <Frank.Vanderlinden@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 03 Jul 2009 02:11:35 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UzZ9LqJXdzaQE/98Ez0P+Pvr9kac0vAswz7GHfpLb+z08YOPdPnNpey0vQPbT08gEU tbjYQwZ0+cM8ivlywxUmX7R4lBWip62/34xDnx/CH6Rbi2lyKYqjAYPTofXt11Ns6ZDV YUai8vZ5Rg3CcRtvZtYbmfbtmENyi2JxdmrHs=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi,

On Fri, Jul 3, 2009 at 10:50 AM, Tim Deegan<Tim.Deegan@xxxxxxxxxx> wrote:
> At 22:42 +0100 on 02 Jul (1246574577), Gianluca Guida wrote:
>> CPU0 doesn't resync a whole L1 page because it's accessing it. There
>> are other reasons for a resync here (especially if the guest is 64
>> bit), but most probably the resync happen because CPU0 is unsyncing
>> another page. Anyway yes, it's highly unlikely but this race can
>> definitely happen. I think I never saw it.
>
> Yes.  The fast-not-present path is safe without OOS because the changing
> L1 would have to be as a result of the guest writing it, which is a race
> on real hardware.   The fast-MMIO path is OK even with OOS because it
> only caches present entries, but for proper safety we might want to
> avoid using fast-path MMIO if the guest maps MMIO space read-only (does
> anyone actually do that?)

Yes, the subject of this thread is incorrect, OOS is incompatible only
with *current* fast gnp code. This bug is easily fixable by checking
if the page is out of sync (and go to the fast path) *before* checking
for the l1 being a special entry. This will remove the race and make
the fast gnp correct again with OOS -- I guess, but I perhaps
shouldn't write about shadow SMP races before breakfast.

But, as I said, there's really no point in keeping the fast gnp path
there already, so I'd be for removing.

>> > I haven't checked the fast emulation path, but similar problems might be
>> > lurking there in combination with OOS.
>>
>> I think that it should be safe enough, but yes another look at it
>> should be worth it.
>
> I think you might as well kill the fast emulation path too, while you're
> in there. :)  The OOS optimization makes it mostly redundant, and it
> just adds complexity now.

Yes, that was on the list as well. Yet, on a correctness point of
view, I think it's safe -- again, no-caffeine warning. The fast
emulation is very simple, and activate in a very particular case: two
emulation in a row, without any other pagefault in between.

Thanks,
Gianluca


-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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