>>> On 26.10.16 at 11:12, <feng...@intel.com> wrote: > >> -----Original Message----- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Tuesday, October 25, 2016 4:09 PM >> To: Wu, Feng <feng...@intel.com> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; >> george.dun...@eu.citrix.com; Tian, Kevin <kevin.t...@intel.com>; xen- >> de...@lists.xen.org >> Subject: RE: [PATCH v5 5/7] VT-d: No need to set irq affinity for posted > format >> IRTE >> >> >>> On 25.10.16 at 03:04, <feng...@intel.com> wrote: >> > I really don't get the point why you think the list is not enough. Could >> > you please explain more, thanks a lot! >> >> I have to admit that I don't really know what else to say. Isn't it >> quite obvious that for you to suppress the actual update, _all_ >> meaningful (in the given format) fields have to match? Unless >> you indeed compare all of them, you make assumptions about >> your callers only covering a subset of all possible inputs. > > Well, the problem is when the current IRTE is in posted mode, and we use > this function to update the IRTE to remapped mode, we cannot compare > all the fields, since they have different format, and that is why I compare > the common field ( other fields are either posted specific or remapped > specific), > it doesn't make sense to compare them between the two format.
Of course, and I've repeatedly said that the first check of course needs to be whether the two format bits are different - if they are, no further checking is needed, and the update must not be bypassed. > Basically, we can divide the format into some category: > - Common field > - posted specific (PI related) or remapped specific (affinity related field) That's fine of course, but any such checks would go after the format bit comparison anyway. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
