On 24/03/2017 05:45, Juergen Gross wrote:
> On 23/03/17 18:35, Andrew Cooper wrote:
>> On 23/03/17 17:12, Tim Deegan wrote:
>>> At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
On 23/03/17 16:55, Tim Deegan wrote:
> At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
On 24/03/2017 07:47, Jan Beulich wrote:
On 23.03.17 at 18:35, wrote:
>> On 23/03/17 17:12, Tim Deegan wrote:
>>> At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
On 23/03/17 16:55, Tim Deegan wrote:
> At 16:31 + on 16 Mar (1489681899),
>>> On 24.03.17 at 08:58, wrote:
> On 24/03/17 08:51, Jan Beulich wrote:
> On 24.03.17 at 06:45, wrote:
>>> On 23/03/17 18:35, Andrew Cooper wrote:
Would you prefer ~((uint64_t)_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)) or
~(_PAGE_PSE_PAT |
On 24/03/17 08:51, Jan Beulich wrote:
On 24.03.17 at 06:45, wrote:
>> On 23/03/17 18:35, Andrew Cooper wrote:
>>> Would you prefer ~((uint64_t)_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)) or
>>> ~(_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1) | 0ULL)
>>
>> Wouldn't it be better to just define
>>> On 24.03.17 at 06:45, wrote:
> On 23/03/17 18:35, Andrew Cooper wrote:
>> Would you prefer ~((uint64_t)_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)) or
>> ~(_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1) | 0ULL)
>
> Wouldn't it be better to just define the _PAGE_PSE bits accordingly?
I don't
>>> On 23.03.17 at 18:35, wrote:
> On 23/03/17 17:12, Tim Deegan wrote:
>> At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
>>> On 23/03/17 16:55, Tim Deegan wrote:
At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
> Some bits are
On 23/03/17 18:35, Andrew Cooper wrote:
> On 23/03/17 17:12, Tim Deegan wrote:
>> At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
>>> On 23/03/17 16:55, Tim Deegan wrote:
At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
> Some bits are unconditionally reserved in
On 23/03/17 17:12, Tim Deegan wrote:
> At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
>> On 23/03/17 16:55, Tim Deegan wrote:
>>> At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
Some bits are unconditionally reserved in pagetable entries, or reserved
because of
At 17:02 + on 23 Mar (1490288548), Andrew Cooper wrote:
> On 23/03/17 16:55, Tim Deegan wrote:
> > At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
> >> Some bits are unconditionally reserved in pagetable entries, or reserved
> >> because of alignment restrictions. Other bits are
On 23/03/17 16:55, Tim Deegan wrote:
> At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
>> Some bits are unconditionally reserved in pagetable entries, or reserved
>> because of alignment restrictions. Other bits are reserved because of
>> control
>> register configuration.
>>
>>
At 16:31 + on 16 Mar (1489681899), Andrew Cooper wrote:
> Some bits are unconditionally reserved in pagetable entries, or reserved
> because of alignment restrictions. Other bits are reserved because of control
> register configuration.
>
> Introduce helpers which take an individual vcpu and
>>> On 16.03.17 at 17:31, wrote:
> Some bits are unconditionally reserved in pagetable entries, or reserved
> because of alignment restrictions. Other bits are reserved because of control
> register configuration.
>
> Introduce helpers which take an individual vcpu
Some bits are unconditionally reserved in pagetable entries, or reserved
because of alignment restrictions. Other bits are reserved because of control
register configuration.
Introduce helpers which take an individual vcpu and guest pagetable entry, and
calculates whether any reserved bits are
13 matches
Mail list logo