On 23.10.2019 14:58, Roger Pau Monné wrote: > On Wed, Oct 23, 2019 at 09:11:54AM +0000, Alexandru Stefan ISAILA wrote: >> >> >> On 03.09.2019 20:24, Tamas K Lengyel wrote: >>> On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich <jbeul...@suse.com> wrote: >>>> >>>> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote: >>>>> --- a/xen/include/public/hvm/hvm_op.h >>>>> +++ b/xen/include/public/hvm/hvm_op.h >>>>> @@ -244,6 +244,7 @@ struct xen_hvm_altp2m_view { >>>>> /* Create view only: default access type >>>>> * NOTE: currently ignored */ >>>>> uint16_t hvmmem_default_access; /* xenmem_access_t */ >>>>> + uint8_t set_sve; /* bool value */ >>>>> }; >>>> >>>> This interface is, given the right configuration, available to >>>> guests. Hence you can't simply add a field here. Just consider >>>> what happens for an existing caller when there is random data >>>> in the field you now assign a meaning. >>> >>> Perhaps instead of extending the HVMOP it would make more sense to >>> just add a xl config option that defines the "default" sve bit for >>> altp2m views in the domain? >>> >> >> Adding a xl config option will not work for systems that do use xl. >> There is a need that this will work in all cases. > > I assume that such option would be implemented using a DOMCTL, which > can also be used by other toolstacks. I however have no idea whether > this is a suitable interface or not for this feature. >
I think that having a HVMOP_altp2m_get_suppress_ve_multi and letting the caller provide the start gfn and the nr of pages to have the sve bits set will provide a good solution for init an dfor further development. I will go on this way for version 2 if everyone is ok with this. Thanks, Alex _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel