On Thu, Jan 09, 2020 at 01:28:21PM +0000, Dr. David Alan Gilbert wrote: > * Roman Kagan (rka...@virtuozzo.com) wrote: > > On Thu, Jan 09, 2020 at 02:00:00PM +0100, Vitaly Kuznetsov wrote: > > > "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > > > > > > > And I think vhost-user will fail if you have too many sections - and > > > > the 16 sections from synic I think will blow the slots available. > > > > > > > > > > SynIC is percpu, it will allocate two 4k pages for every vCPU the guest > > > has so we're potentially looking at hundreds of such regions. > > > > Indeed. > > > > I think my original idea to implement overlay pages word-for-word to the > > HyperV spec was a mistake, as it lead to fragmentation and memslot > > waste. > > > > I'll look into reworking it without actually mapping extra pages over > > the existing RAM, but achieving overlay semantics by just shoving the > > *content* of the "overlaid" memory somewhere. > > > > That said, I haven't yet fully understood how the reported issue came > > about, and thus whether the proposed approach would resolve it too. > > The problem happens when we end up with: > > a) 0-512k RAM > b) 512k + synic > c) 570kish-640k RAM > > the page alignment code rounds > (a) to 0-2MB - aligning to the hugepage it's in > (b) leaves as is > (c) aligns to 0-2MB > > it then tries to coalesce (c) and (a) and notices (b) got in the way > and fails it.
I see, thanks. The only bit I still haven't quite followed is how this failure results in a quiet vhost malfunction rather than a refusal to start vhost. > Given the guest can put Synic anywhere I'm not sure that changing it's > implementatino would help here. There would be no (b) nor (separate) (c): synic would just refer to some memory straight from (a), regardless of its paging granularity. > (And changing it's implementation would probably break migration > compatibility). I'm afraid I see no better option. Thanks, Roman.
