[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings


  • To: 'Jan Beulich' <jbeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Tue, 24 Sep 2019 09:08:46 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=Paul.Durrant@xxxxxxxxxx; spf=Pass smtp.mailfrom=Paul.Durrant@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Delivery-date: Tue, 24 Sep 2019 09:09:00 +0000
  • Ironport-sdr: uF/pypIRi3RpByx/RuiInuaKQrSGDVqhg025xrSgRHOqCrB6iuMzmoAWwnV+5bJ6LkEFpBg0rc fTYvf3fQN88qUqflY2onzqwvyW9iuRqmEt6VxcJvuJgf6f4t5bejUqCVEXN3MJRnRaZ6osmjiK X2wPg1onKaDw1nw8g34BwuLqZTZFFJ5iknP0XHT+5qFecAR7k1M+PbUUNymXR3vZaPu59KvDXn 4jX4kLE82JPDrIunY4wPiOIXYY36O4u5pnRIFh+3lfb4TA/Vr9Pe6zLReUpRrCQX0ePDTikhvM SPI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVbu3E2x13CiTrgkyIxcLuJ2Ba16c5eODggAD1DYCAACHJcA==
  • Thread-topic: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings


> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 24 September 2019 10:02
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Suravee Suthikulpanit 
> <suravee.suthikulpanit@xxxxxxx>; Andrew
> Cooper <Andrew.Cooper3@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings
> 
> On 23.09.2019 18:25, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan 
> >> Beulich
> >> Sent: 19 September 2019 14:24
> >> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Suravee Suthikulpanit
> <suravee.suthikulpanit@xxxxxxx>
> >> Subject: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings
> >>
> >> Move the device flags field up into an unused hole, thus shrinking
> >> overall structure size by 8 bytes. Use bool and uint<N>_t as
> >> appropriate. Drop pointless (redundant) initializations.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >
> > Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> 
> Thanks.
> 
> > ...although I wonder...
> >
> >> --- a/xen/include/asm-x86/amd-iommu.h
> >> +++ b/xen/include/asm-x86/amd-iommu.h
> >> @@ -106,12 +106,16 @@ struct amd_iommu {
> >>  };
> >>
> >>  struct ivrs_mappings {
> >> -    u16 dte_requestor_id;
> >> -    u8 dte_allow_exclusion;
> >> -    u8 unity_map_enable;
> >> -    u8 write_permission;
> >> -    u8 read_permission;
> >> +    uint16_t dte_requestor_id;
> >>      bool valid;
> >> +    bool dte_allow_exclusion;
> >> +    bool unity_map_enable;
> >> +    bool write_permission;
> >> +    bool read_permission;
> >
> > Could you shrink this even more by using a bit-field instead of this 
> > sequence of bools?
> 
> Indeed I had been considering this. Besides the fact that making
> such a move simply didn't look to fit other things here very well
> when introducing the "valid" flag in an earlier path, and then
> also not here, do you realize though that this wouldn't shrink
> the structure's size right now (i.e. it would only be potentially
> reducing future growth)?

Yes, I'd failed to note the 'unsigned long' afterwards, but...

> This was my main argument against going
> this further step; let me know what you think.
> 

I still think a pre-emptive squash into a uint8_t bit-field followed by the 
device_flags field would give the struct a nice 32-bit hole for potential 
future use.

  Paul

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.