On Thu, Feb 14, 2019 at 08:22:05AM +0000, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Thursday, February 14, 2019 4:13 PM > > > > On Thu, Feb 14, 2019 at 07:35:20AM +0000, Tian, Kevin wrote: > > > > From: Peter Xu [mailto:pet...@redhat.com] > > > > Sent: Thursday, February 14, 2019 3:14 PM > > > > > > > > > > > > > > > When 256 bits invalidation descriptor is used, the guest driver > > > > > > should be responsible to fill in zeros into reserved fields. > > > > > > > > > > > > Another question: is val[2] & val[3] used in any place even with > > > > > > 256bits mode? From what I see from the spec (chap 6.5.2), all of > > them > > > > > > seems to be reserved as zeros, then I don't understand why bother > > > > > > extending this to 256bits... Did I miss something? > > > > > > > > > > > > PRQ is extended to carry larger private data which requires 256bits > > > mode. You can take a look at 7.5.1.1 Page Request Descriptor. > > > > But we are talking about IQ (Invalidation Queue), not PRQ, right? > > > > I see that Page Request Queue seems to always have 256bits descriptors > > (chap 10.4.32, there is no Descriptor Width field, and I think it > > means DW==1 always), however the Invalidation Queue seems to support > > both modes (chap 10.4.23, there is Descriptor Width field, DW==0 > > should be the legacy mode, and DW==1 should be the new mode). While, > > none of the invalidate descriptors described in chap 6.5.2 is using > > the upper 128bits even if 256bits mode is supported. > > > > Page Group Response descriptor is composed by software through > invalidation queue, which needs to carry same private data back > (as in page request descriptor). it's described in 7.7.1.
I see the point. Thanks, Kevin. Regards, -- Peter Xu
