Re: [PATCH v2 0/4] Fix accessed bit tracking

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

 



On 06/08/2010 09:53 AM, Xiao Guangrong wrote:

Avi Kivity wrote:
On 06/08/2010 05:35 AM, Xiao Guangrong wrote:
We can avoid the exchange in most cases, for example if the new spte has
the accessed bit set (already in the patch set) or if the page is
already marked as accessed, or if we see the old spte has the accessed
bit set (so no race can occur).  I'll update the patches to avoid
atomics when possible.

Umm, the reason that we need atomics here is to avoid vcpu to update
spte when we read A bit
form it, so, perhaps we can use below way to avoid atomics completely:

- set reserved bit in spte
- get A bit form spte
- set new spte

the worst case is cause vcpu #PF here, but it doesn't matter since the
old mapping is already invalid,
also need a remote tlb flush later.

To set the reserved bit in the spte, you need an atomic operation (well,
unless you use a sub-word-acccess to set a reserved bit in the high 32
bits).
I think we no need atomic here, for example, we can do it like this:

*spte |= RSVD_BIT
[ maybe need a write barrier here? ]

That can drop an A bit.  If *spte starts out with A cleared, we can have

cpu0                        cpu1

fetch *spte (A=0)
                            set A bit
write *spte (A=0, RSVD=1)


After this sentence completed, we can ensure that the spte can not updated A bit
by vcpu, so we can get A bit safely.

You also need a remote tlb flush...

Yes, but atomics are "LOCK" instructions, it can stop multiple cpus
runing in parallel.

Only if those cpus are accessing the same word you're accessing.

Oh, you are right, the LOCK only locked the memory defined by the destination operand,
but i also recall that page table access can pass LOCK instruction, below description
is form intel' spec Vol. 3 7-5:

Locked operations are atomic with respect to all other memory operations and all externally
visible events. Only instruction fetch and page table accesses can pass locked instructions.
Locked instructions can be used to synchronize data written by one processor and read by another
processor.

But actually setting the A bit will use LOCK itself. So in the following sequence


   write pte (A=0)
   test_and_clear_bit(A, pte)
   access memory through pte

the test_and_clear_bit can return A=1 due to speculation and the parapgraph above, but setting the A bit by the processor will happen with a bus lock, so it won't lose information.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux