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

Re: [Xen-devel] [PATCH v2] x86/hvmloader: round up memory BAR size to 4K



On Tue, Jan 21, 2020 at 11:43:58AM +0100, Jan Beulich wrote:
> On 21.01.2020 11:29, Roger Pau Monné wrote:
> > So I'm not sure how to progress with this patch, are we fine with
> > those limitations?
> 
> I'm afraid this depends on ...
> 
> > As I said, Xen hasn't got enough knowledge to correctly isolate the
> > BARs, and hence we have to rely on dom0 DTRT. We could add checks in
> > Xen to make sure no BARs share a page, but it's a non-trivial amount
> > of scanning and sizing each possible BAR on the system.
> 
> ... whether Dom0 actually "DTRT", which in turn is complicated by there
> not being a specific Dom0 kernel incarnation to check against. Perhaps
> rather than having Xen check _all_ BARs, Xen or the tool stack could
> check BARs of devices about to be handed to a guest? Perhaps we need to
> pass auxiliary information to hvmloader to be able to judge whether a
> BAR shares a page with another one? Perhaps there also needs to be a
> way for hvmloader to know what offset into a page has to be maintained
> for any particular BAR, as follows from Jason's recent reply?

Linux has an option to force resource alignment (as reported by
Jason), maybe we could force all BARs to be aligned to page size in
order to be passed through?

That would make it easier to check (as Xen/Qemu would only need to
assert that the BAR address is aligned), and won't require much extra
work in Xen apart from the check itself.

Do you think this would be an acceptable solution?

Thanks, Roger.

_______________________________________________
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®.