netdev - RE: [PATCH V2 vfio 03/11] vfio: Introduce DMA logging uAPIs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB52767FB07E8C4F3C3059A1658C959@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Mon, 25 Jul 2022 07:20:16 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Yishai Hadas <yishaih@...dia.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "Martins, Joao" <joao.m.martins@...cle.com>,
        "leonro@...dia.com" <leonro@...dia.com>,
        "maorg@...dia.com" <maorg@...dia.com>,
        "cohuck@...hat.com" <cohuck@...hat.com>
Subject: RE: [PATCH V2 vfio 03/11] vfio: Introduce DMA logging uAPIs

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Thursday, July 21, 2022 8:05 PM
> 
> On Thu, Jul 21, 2022 at 08:45:10AM +0000, Tian, Kevin wrote:
> 
> > > + * will format its internal logging to match the reporting page size,
> possibly
> > > + * by replicating bits if the internal page size is lower than requested.
> >
> > what's the purpose of this? I didn't quite get why an user would want to
> > start tracking in one page size and then read back the dirty bitmap in
> > another page size...
> 
> There may be multiple kernel trackers that are working with different
> underlying block sizes, so the concept is userspace decides what block
> size it wants to work in and the kernel side transparently adapts. The
> math is simple so putting it in the kernel is convenient.
> 
> Effectively the general vision is that qemu would allocate one
> reporting buffer and then invoke these IOCTLs in parallel on all the
> trackers then process the single bitmap. Forcing qemu to allocate
> bitmaps per tracker page size is just inefficient.
> 

I got that point. But my question is slightly different.

A practical flow would like below:

1) Qemu first requests to start dirty tracking in 4KB page size.
   Underlying trackers may start tracking in 4KB, 256KB, 2MB,
   etc. based on their own constraints.

2) Qemu then reads back dirty reports in a shared bitmap in
   4KB page size. All trackers must update dirty bitmap in 4KB
   granular regardless of the actual size each tracker selects.

Is there a real usage where Qemu would want to attempt
different page sizes between above two steps?

If not then I wonder whether a simpler design is to just have 
page size specified in the first step and then inherited by the 
2nd step...

Thanks
Kevin