Re: [Xen-devel] [PATCH v7 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.03.17 at 08:28, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
> On 3/13/2017 7:20 PM, Jan Beulich wrote:
>>>>> On 11.03.17 at 09:42, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
>>> On 3/10/2017 11:29 PM, Jan Beulich wrote:
>>>>>>> On 08.03.17 at 16:33, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
>>>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>>>> @@ -131,6 +131,13 @@ static void ept_p2m_type_to_flags(struct p2m_domain 
>>>>> *p2m, ept_entry_t *entry,
>>>>>                entry->r = entry->w = entry->x = 1;
>>>>>                entry->a = entry->d = !!cpu_has_vmx_ept_ad;
>>>>>                break;
>>>>> +        case p2m_ioreq_server:
>>>>> +            entry->r = 1;
>>>>> +            entry->w = !(p2m->ioreq.flags & 
>>>>> XEN_DMOP_IOREQ_MEM_ACCESS_WRITE);
>>>> Along the lines of the previous comment - if you mean to have the
>>>> code cope with READ, please also set ->r accordingly, or add a
>>>> comment why this won't have the intended effect (yielding a not
>>>> present EPTE).
>>> How about we keep this code and do not support READ? I'll remove above
>>> dead code in hvmemul_do_io().
>> Sure, as said above: All I'd like to push for is that the result is
>> consistent across the code base.
> 
> Thank you, Jan. I should have keep a consistent principle in this code.
> My preference is to remove the possible read emulation logic. But could 
> we still keep the
> definition of XEN_DMOP_IOREQ_MEM_ACCESS_READ, so that people can still 
> know this
> interface can be extended in the future?

Of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel