On Fri, Feb 23, 2018 at 01:22:23PM +0800, Chao Gao wrote:
> On Mon, Feb 12, 2018 at 02:49:12PM +0000, Roger Pau Monné wrote:
> >On Fri, Nov 17, 2017 at 02:22:24PM +0800, Chao Gao wrote:
> >
> >> +struct hvm_hw_vvtd
> >> +{
> >> +    uint32_t eim_enabled : 1,
> >> +             intremap_enabled : 1;
> >> +    uint32_t fault_index;
> >> +
> >> +    /* Interrupt remapping table base gfn and the max of entries */
> >> +    uint32_t irt_max_entry;
> >> +    uint64_t irt;
> >> +
> >> +    uint32_t regs[VVTD_MAX_OFFSET/sizeof(uint32_t)];
> >> +};
> >> +
> >> +DECLARE_HVM_SAVE_TYPE(VVTD, 21, struct hvm_hw_vvtd);
> >
> >Adding new fields to this struct in a migration compatible way is
> >going to be a PITA, but there's no easy solution to this I'm afraid...
> 
> What do you mean by "migration compatible"? Do you mean migrating a hvm
> guest with viommu between different Xen versions? Could it be solved by
> leaving some padding fields here?

It's inevitable, but when new features are added to the vvtd
implementation the struct will likely change and then we will need
some conversion helper.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to