On 13/01/16 17:03, Boris Ostrovsky wrote:
> On 01/13/2016 11:30 AM, Andrew Cooper wrote:
>> On 13/01/16 16:26, Jan Beulich wrote:
>> On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVM
On 01/13/2016 11:30 AM, Andrew Cooper wrote:
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
>> On 13/01/16 16:13, Jan Beulich wrote:
>> On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I would like to com
>>> On 13.01.16 at 17:17, wrote:
> On 13/01/16 16:13, Jan Beulich wrote:
> On 13.01.16 at 16:49, wrote:
>>> Hello,
>>>
>>> While working on a HVMlite Dom0 implementation I've found a couple of
>>> loose ends with the design that I would like to comment because it's not
>>> clear to me what's
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM C
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID
On 13/01/16 17:01, Roger Pau Monné wrote:
> El 13/01/16 a les 16.56, Juergen Gross ha escrit:
>> On 13/01/16 16:49, Roger Pau Monné wrote:
>>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>>> and from the Xen domain builder for HVMlite Dom0. This again implies
>>> some fu
>>> On 13.01.16 at 16:49, wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID is h
>>> On 13.01.16 at 16:54, wrote:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM CPUID an
El 13/01/16 a les 16.54, David Vrabel ha escrit:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> 2. HVM MTRR and Dom0.
>>
>> MTRR ranges are initialised from hvmloader, which means that although we
>> expose the MTRR functionality to HVMlite guests (and AFAICT the
>> functionality is fully complete/
El 13/01/16 a les 16.56, Juergen Gross ha escrit:
> On 13/01/16 16:49, Roger Pau Monné wrote:
>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>> and from the Xen domain builder for HVMlite Dom0. This again implies
>> some functional duplication of MTRR related code, since
On 13/01/16 16:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CP
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
I think Andy's pendi
13 matches
Mail list logo
