>>> On 11.12.17 at 16:54, wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
> On 11.12.17 at 15:51, wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wro
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
wrote:
> From: Razvan Cojocaru
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2
On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
wrote:
> From: Razvan Cojocaru
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2
On 12/11/2017 06:00 PM, Tamas K Lengyel wrote:
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there. The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to r
On Mon, Dec 11, 2017 at 8:05 AM, Jan Beulich wrote:
On 11.12.17 at 15:51, wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12
On 12/11/2017 05:54 PM, George Dunlap wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
> On 11.12.17 at 15:51, wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan
On 12/11/2017 03:05 PM, Jan Beulich wrote:
On 11.12.17 at 15:51, wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12:06, wrot
On 12/11/2017 02:58 PM, Jan Beulich wrote:
On 11.12.17 at 15:50, wrote:
>> On 12/11/2017 01:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
You argued that we should keep PV linear pagetables, before knowing that
NetBSD used them, in spite of having discovered two *ac
>>> On 11.12.17 at 15:51, wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> My suggestion was that we don't break u
>>> On 11.12.17 at 15:46, wrote:
> Quite likely I'm not grasping the full meaning of your objection,
> however the added code is merely another interface to already existing
> core code - so while admittedly there's room for improvement for the EPT
> code below it, this patch really only extends t
>>> On 11.12.17 at 15:50, wrote:
> On 12/11/2017 01:36 PM, Jan Beulich wrote:
> On 11.12.17 at 13:50, wrote:
>>> You argued that we should keep PV linear pagetables, before knowing that
>>> NetBSD used them, in spite of having discovered two *actual*
>>> vulnerabilities in the implementation.
On 12/11/2017 02:51 PM, George Dunlap wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>> On 11.12.17 at 13:50, wrote:
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> My suggestion was that we do
On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
> On 12/11/2017 03:36 PM, Jan Beulich wrote:
> On 11.12.17 at 13:50, wrote:
>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>> On 11.12.17 at 12:06, wrote:
> My suggestion was that we don't break usecases. The Intel usecase
> specifi
On 12/11/2017 01:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>> On 11.12.17 at 12:06, wrote:
My suggestion was that we don't break usecases. The Intel usecase
specifically is for an in-guest entity to have full control o
On 12/11/2017 03:36 PM, Jan Beulich wrote:
On 11.12.17 at 13:50, wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>> On 11.12.17 at 12:06, wrote:
My suggestion was that we don't break usecases. The Intel usecase
specifically is for an in-guest entity to have full control o
>>> On 11.12.17 at 13:50, wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
> On 11.12.17 at 12:06, wrote:
>>> My suggestion was that we don't break usecases. The Intel usecase
>>> specifically is for an in-guest entity to have full control of all
>>> altp2m functionality, and this is fine
On 12/11/2017 12:12 PM, Jan Beulich wrote:
On 11.12.17 at 12:06, wrote:
>> On 11/12/17 09:14, Jan Beulich wrote:
>> On 08.12.17 at 13:42, wrote:
On 12/08/2017 02:18 PM, Jan Beulich wrote:
On 24.10.17 at 12:19, wrote:
>> HVMOP_altp2m_set_mem_access_multi has been added
>>> On 08.12.17 at 13:42, wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
> On 24.10.17 at 12:19, wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart
>>> (and
>>> hence with t
On 11/12/17 09:14, Jan Beulich wrote:
On 08.12.17 at 13:42, wrote:
>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>> On 24.10.17 at 12:19, wrote:
HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to
a
DOMCTL) for consistency with its HVMOP_altp2m_set_
>>> On 11.12.17 at 12:06, wrote:
> On 11/12/17 09:14, Jan Beulich wrote:
> On 08.12.17 at 13:42, wrote:
>>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>> On 24.10.17 at 12:19, wrote:
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed
> to a
> DOMCTL)
On Fri, Dec 8, 2017 at 5:42 AM, Razvan Cojocaru
wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
> On 24.10.17 at 12:19, wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart
>>>
On 12/08/2017 02:18 PM, Jan Beulich wrote:
On 24.10.17 at 12:19, wrote:
>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>> hence with the original altp2m design, where domains are
>>> On 24.10.17 at 12:19, wrote:
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access right
23 matches
Mail list logo
