On 2018-06-30 08:05, Paolo Bonzini wrote:
> On 30/06/2018 07:25, Jan Kiszka wrote:
>> On 2018-06-27 14:14, Paolo Bonzini wrote:
>>> On 03/04/2018 17:36, Jan Kiszka wrote:
>>>>
>>>> +static hwaddr get_hphys(CPUState *cs, hwaddr gphys, MMUAccessType
>>>> access_type,
>>>> + int *prot)
>>>> +{
>>>> + CPUX86State *env = &X86_CPU(cs)->env;
>>>> + uint64_t rsvd_mask = PG_HI_RSVD_MASK;
>>>> + uint64_t ptep, pte;
>>>> + uint64_t exit_info_1 = 0;
>>>> + target_ulong pde_addr, pte_addr;
>>>> + uint32_t page_offset;
>>>> + int page_size;
>>>> +
>>>> + if (likely(!(env->hflags & HF_NPT_MASK))) {
>>>> + return gphys;
>>>> + }
>>>
>>> hflags are a somewhat limited resource. Can this go in hflags2?
>>>
>>
>> Will have a look - I don't seen why not. Or is there any special
>> semantical difference between both fields?
>
> Yes, hflags become flags of the translation block, while hflags2 are
> just random processor state. If translate.c uses it you must use
> hflags, but here hflags2 should be safe.Indeed. We only change it at vmentry/exit, and that is already a translation block barrier. v2 is on the way. Jan
signature.asc
Description: OpenPGP digital signature
