Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

[Jason Wang <jasowang@redhat.com>]

On Fri, Apr 14, 2023 at 11:22âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, April 13, 2023 11:18 PM
>
> > > >
> > > > It's a must for ABI and migration compatibility:
> > > >
> > > > 1) The offset is not necessarily a page boundary
> > > > 2) The length is not necessarily times of a PAGE_SIZE
> > > > 3) PAGE_SIZE varies among different archs
> > > > 4) Two vendors may have two different layout for the structure
> > >
> > > Migration compatibility check and device composition work will start for
> > regular PCI VF in virtio.
> > > Two vendors will had some level of programmability as well to make this
> > happen.
> > > It is orthogonal topic.
> >
> > Actually not, having new blockers for live migration will complicate the solution
> > in the future.
> >
> It is not a blocker, its just another flexible field that hw vendors will align to a common way to configure.
>
> Just to make sure this is the BAR0 size, right?

We're discussing "if mediating 1.x device is a must" as I reply to
what you said:

"
Trapping non legacy accessing for 1.x doesn't make sense.
"

>
> > And 1) 2) 3) can happen even if we don't care about migration compatibility,
> > no?
>
> I guess one we have spec definition, it wont be a problem.

How can you assign a cap length 4K to a guest assuming 8K as page size?

Thanks