[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 07/12] x86/altp2m: add control of suppress_ve.
On 06/25/2015 11:04 PM, Jan Beulich wrote: >>>> On 25.06.15 at 18:36, <edmund.h.white@xxxxxxxxx> wrote: >> On 06/25/2015 01:12 AM, Jan Beulich wrote: >>>>>> On 24.06.15 at 19:53, <edmund.h.white@xxxxxxxxx> wrote: >>>> On 06/24/2015 07:38 AM, Jan Beulich wrote: >>>>>>>> On 22.06.15 at 20:56, <edmund.h.white@xxxxxxxxx> wrote: >>>>>> --- a/xen/include/asm-x86/p2m.h >>>>>> +++ b/xen/include/asm-x86/p2m.h >>>>>> @@ -237,6 +237,19 @@ struct p2m_domain { >>>>>> p2m_access_t *p2ma, >>>>>> p2m_query_t q, >>>>>> unsigned int *page_order); >>>>>> + int (*set_entry_full)(struct p2m_domain *p2m, >>>>>> + unsigned long gfn, >>>>>> + mfn_t mfn, unsigned int >>>> page_order, >>>>>> + p2m_type_t p2mt, >>>>>> + p2m_access_t p2ma, >>>>>> + unsigned int sve); >>>>>> + mfn_t (*get_entry_full)(struct p2m_domain *p2m, >>>>>> + unsigned long gfn, >>>>>> + p2m_type_t *p2mt, >>>>>> + p2m_access_t *p2ma, >>>>>> + p2m_query_t q, >>>>>> + unsigned int *page_order, >>>>>> + unsigned int *sve); >>>>> >>>>> I have to admit that I find the _full suffixes here pretty odd. Based >>>>> on the functionality, they should be _sve. But then it seems >>>>> questionable how they could be useful to the generic p2m layer >>>>> anyway, i.e. why there would need to be such hooks in the first >>>>> place. >>>> >>>> I did originally use _sve suffixes. I changed them because there >>>> may be some future case where these routines control some other >>>> EPTE bit too. I made them hooks because I thought calling ept... >>>> functions directly would be a layering violation. >>> >>> Indeed it would. But thinking about it more, I would suggest to >>> extend the existing accessors rather than adding new ones. >>> Just consider what would result when further such return values >>> are going to be needed in the future: I don't see us adding >>> _fuller, _fullest, etc variants. Perhaps just make the new output >>> an optional generic "flags" one. One might even consider folding >>> it with order, or even consolidate all the outputs into a single >>> structure. >> >> The new functions are called in 3 places only, so changing them >> later would have minimal impact. The existing functions are called >> in many, many places. I *really* don't want to go changing the >> amount of existing code that doing what you suggest would entail >> at this late stage. > > I continue to think differently (and I don't consider "at this late > stage" a particularly relevant argument), but the maintainer will > have the final say anyway - George? > The patch as it is now doesn't disturb (and risk breaking) any existing code. I'd much rather stick with that for 4.6, even if only on the condition that I have to change it later. If I do what you suggest, that sets me up to fail to get anything in 4.6. That may not matter to you, but it matters to me. Ed _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |