On Wed, Mar 22, 2017 at 9:40 AM, Tamas K Lengyel
wrote:
> On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich wrote:
> On 21.03.17 at 18:25, wrote:
>>> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
Hmm, the original (abstract) VMFUNC use case, as I have
understood it, allows a gue
On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich wrote:
On 21.03.17 at 18:25, wrote:
>> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
>>> Hmm, the original (abstract) VMFUNC use case, as I have
>>> understood it, allows a guest to actively select between EPT
>>> variants without having (
>>> On 21.03.17 at 18:25, wrote:
> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
>> Hmm, the original (abstract) VMFUNC use case, as I have
>> understood it, allows a guest to actively select between EPT
>> variants without having (direct) control over their contents.
>
> Correct. But eve
On Mon, Mar 20, 2017 at 01:27:26PM -0600, Tamas K Lengyel wrote:
>
> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
> (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
> - libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) {
> +(libxl_defbool_val(d_conf
On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich wrote:
On 21.03.17 at 18:09, wrote:
>> On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
>> On 21.03.17 at 17:43, wrote:
On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
On 21.03.17 at 17:30, wrote:
>> On Tue, Mar
>>> On 21.03.17 at 18:09, wrote:
> On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
> On 21.03.17 at 17:43, wrote:
>>> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
>>> On 21.03.17 at 17:30, wrote:
> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>> Furthermore
On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich wrote:
On 21.03.17 at 17:43, wrote:
>> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
>> On 21.03.17 at 17:30, wrote:
On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>>> On 21.03.17 at 17:43, wrote:
> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
> On 21.03.17 at 17:30, wrote:
>>> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
supposed to always be available to the guest (as long
On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich wrote:
On 21.03.17 at 17:30, wrote:
>> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>>> supposed to always be available to the guest (as long as altp2m
>>> is enabled)? You don't all
>>> On 21.03.17 at 17:30, wrote:
> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>> supposed to always be available to the guest (as long as altp2m
>> is enabled)? You don't allow this here anymore.
>
> Absolutely not, that's one of th
On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich wrote:
On 20.03.17 at 20:27, wrote:
>> Signed-off-by: Tamas K Lengyel
>> Signed-off-by: Sergej Proskurin
>> Acked-by: Jan Beulich
>
> I'll need to make this conditional upon a few more adjustments:
>
>> @@ -4370,18 +4370,19 @@ static int do_alt
>>> On 20.03.17 at 20:27, wrote:
> Signed-off-by: Tamas K Lengyel
> Signed-off-by: Sergej Proskurin
> Acked-by: Jan Beulich
I'll need to make this conditional upon a few more adjustments:
> @@ -4370,18 +4370,19 @@ static int do_altp2m_op(
> goto out;
> }
>
> -if ( (rc = xs
Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropri
13 matches
Mail list logo
