Linux Virtualization - Apr 2007 - Heads up

Jeremy Fitzhardinge wrote:
> 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.
I'll add it back.  I didn't think about HVM issues fully...

Jeremy Fitzhardinge wrote:
> 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?
I'm using yap, which is built on top of quilt.  I fixed it to parse the 
patches properly, but it still leaves Index: lines when I regenerate 
patches, which I can't really help.

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