Re: [Xen-devel] [PATCH v4 2/2] x86/PV: support data breakpoint extension registers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.04.14 at 14:39, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Wed, 2014-04-23 at 13:35 +0100, Jan Beulich wrote:
>> >>> On 23.04.14 at 14:23, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>> > All makes sense. Worth a comment though?
>> 
>> Not sure - it's no more subtle than other code in the handling of that
>> specific sub-hypercall. But yes, by my own argumentation elsewhere
>> maybe I shouldn't be extending badness - if only I saw ways of
>> describing things like this without just converting C to human language
>> (which doesn't seem all that helpful)...
> 
> Nothing the behaviour of msr_count you describe doesn't sound like just
> converting the C to human readable to me, unless you expect readers of
> this interface header to go digging into the implementation to figure
> this out, which shouldn't be needed (that's the point of docs after all!)

Oh, right, I didn't realize your comment was in the context of the
public header changes - I blindly assumed them to be on the code
implementing the interface extension. Will see to put something like
the above in there.

>> >> So as is the tools are fine not explicitly setting msr_count (it's being
>> >> implicitly set to zero) - state save will fail in that case. It's the 3rd
>> >> (unfinished and now delayed until after Andrew's re-write) patch
>> >> that would be dealing with that error, re-issuing the call after
>> >> allocating a suitable array.
>> > 
>> > That would be a bisection hazard wouldn't it?
>> 
>> Only with guests using the extension and wanting to be migrated.
> 
> I hadn't realised there was this condition as well (since hte feature
> looks more generic at the level I'm looking at it).
> 
> So any such guests would fail to migrate today anyway, right?

I think such a guest wouldn't make it to migration, but would rather be
killed (by sending it a #GP it may not expect) for an invalid MSR write.
I.e. the improvement of this patch is to make it work at all, but fail on
attempts to be migrated.

Jan


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