[Top][All Lists]

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

Re: [PATCH 2/2] hyperv/synic: Allocate as ram_device

From: Dr. David Alan Gilbert
Subject: Re: [PATCH 2/2] hyperv/synic: Allocate as ram_device
Date: Thu, 9 Jan 2020 15:38:00 +0000
User-agent: Mutt/1.13.0 (2019-11-30)

* Paolo Bonzini (address@hidden) wrote:
> On 09/01/20 14:22, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (address@hidden) wrote:
> >> On Thu, Jan 09, 2020 at 12:22:37PM +0000, Dr. David Alan Gilbert wrote:
> >>> Do we want a new memory_region_init for that or just to be able to add
> >>> a flag?
> >>>
> >> I think a flag API is preferable since this can apply to any kind of
> >> region. But can go either way, Paolo's the maintainer there.
> > 
> > (Copying Paolo in)
> > So what exactly does this flag mean; to me it's 'no vhost' - but is it
> > actually more general?
> It has two more effects in addition to no vhost:
> 1) it is skipped when dumping the guest (is this a good or bad idea for
> SynIC?)
> 2) accesses to the region will use the specified size (e.g. 4-bytes for
> address_space_stl, 1-byte for address_space_stb) instead of a memcpy.
> Doesn't really matter for SynIC regions.
> If (1) is a good idea, then it's 2 out of 3 and I guess the patch is okay.

It's probably best  to keep them in the dump because they give some info
on the current state of the windows guest and interrupts.
Also, as Roman points out the ram-device pages aren't migrated, so we
need to fix that as well.

So, do we add a new flag? If so, is no-vhost what we want?


> Paolo
Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

[Prev in Thread] Current Thread [Next in Thread]