Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
>> Zachary Amsden wrote:
>>> I removed sync_core from paravirt ops (it is always a raw cpuid in
>>> all cases). I didn't want to touch Jeremy's patch 020 and cause
>>> sync problems for him, so I haven't removed it there.
>> It wouldn't necessarily be cpuid on an hvm guest.
>
> Yes, CPUID could be more heavyweight there, but do you anticipate it
> moving into any fast paths?
>
> And why do you need a serialization barrier at all? Speculative
> execution is only dangerous if you have potential conflicting memory
> types such that you can cache and then writeback regions of memory
> which should be uncached. But that is a bug anyway, and should be
> fixed up by properly setting the MTRRs for I/O space. Or workarounds
> for processor bugs. The only real user (other than this patch) is the
> Intel microcode update driver. Memory serialization is sufficient in
> all other cases on x86.
One could imagine someone wanting to use it in a timing loop or
something, and a 100x or 1000x slowdown might ruin their day.
But it's not really all that important. I don't really see a good
reason to not have a separate sync_core operation, but we can always add
it later if needed.
The bigger immediate issue is that we seem to be having an emerging
tools compatibility problem; all those Index: lines you added will get
removed when I refresh the patch. I'm using the mercurial mq extension,
as is Rusty, and Chris is using a combination of mq and quilt. What are
you using? Why can't it deal with the patches?
J
