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

Re: [Xen-devel] [PATCH 3/3] x86emul: consolidate CR4 handling



>>> On 02.11.18 at 19:24, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 02/11/18 16:46, Jan Beulich wrote:
>> Now that there's an almost unconditional CR4 read right at the beginning
>> of x86_emulate(), centralize its reading there and use result and value
>> everywhere else without further invoking the hook.
>>
>> Subsequently we may want to consider having the callers provide
>> whichever value they deem appropriate in their contexts, to avoid
>> invoking the hook altogether for this purpose.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I've got most of a series doing this for cpuid, which drops ~4k of .text
> volume from x86_emulate() alone.
> 
> My plan was to get all the architectural state in a directly readable
> form, to reduce the complexity and boilerplate.

I'm not convinced, the more that I don't think you really mean "all"
when you say "all": Surely not the whole set of MSRs or any of
XSTATE?

>  On that subject...
> 
>> @@ -3247,6 +3245,8 @@ x86_emulate(
>>  
>>      ASSERT(ops->read);
>>  
>> +    cr4_rc = ops->read_cr ? ops->read_cr(4, &cr4, ctxt) : X86EMUL_OKAY;
> 
> ... why not make read_cr() mandatory, or put cr4 into ctxt?  Plumbing
> cr4_rc around still feels like a lot of boilerplate.

read_cr() is not currently populated by all paths; see
hvm_emulate_one_mmio() for one example. I don't want to make
the hook mandatory, at least not yet.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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