[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request |
Date: |
Mon, 17 Jul 2017 19:58:31 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
* Edgar E. Iglesias (address@hidden) wrote:
> On Mon, Jul 17, 2017 at 11:33 PM, Peter Maydell <address@hidden>
> wrote:
>
> > On 14 June 2017 at 18:45, Edgar E. Iglesias <address@hidden>
> > wrote:
> > > From: "Edgar E. Iglesias" <address@hidden>
> > > Paolo suggested offline that we send a pull request for this series.
> > > Here it is, I've run it through my testsuite + tested the LQSPI testcase
> > > on Zynq.
> >
> > > ----------------------------------------------------------------
> > > mmio-exec.for-upstream
> > >
> > > ----------------------------------------------------------------
> > > KONRAD Frederic (7):
> > > cputlb: cleanup get_page_addr_code to use VICTIM_TLB_HIT
> > > cputlb: move get_page_addr_code
> > > cputlb: fix the way get_page_addr_code fills the tlb
> > > qdev: add MemoryRegion property
> > > introduce mmio_interface
> > > exec: allow to get a pointer for some mmio memory region
> > > xilinx_spips: allow mmio execution
> >
> > Hi Edgar -- can you or Fred explain how this code interacts with
> > VM migration? The mmio-interface device creates a RAM memory
> > region with memory_region_init_ram_ptr(), but it doesn't call
> > vmstate_register_ram(). On the other hand the core migration code
> > will try to migrate the contents of the RAMBlock anyway, just
> > without a name.
> >
> > It's not clear to me how this works, and it would be nice to
> > get it clear so that we can make any necessary fixes before the
> > 2.10 release hits and we lose the opportunity to make any
> > migration-compatibility-breaking changes.
> >
> > thanks
> > -- PMM
> >
>
> Hi Peter,
>
> These temporary regions should be read-only and treated as temporary caches
> AFAIU things.
> I would say that they don't need to be migrated. After migration, the new
> VM will recreate the ram areas from device backing.
>
> Is there a way we can prevent migration of the RAMBlock?
Not yet, I think we'd have to:
a) Add a flag to the RAMBlock
b) Set it/clear it on registration
c) Have a RAMBLOCK_FOREACH_MIGRATABLE macro
d) Replace all of the RAMBLOCK_FOREACH (and the couple of hand coded
cases) with the RAMBLOCK_FOREACH_MIGRATABLE
e) Worry about the corner cases!
I've got a few worries about what happens when the kernel tries to
do dirty yncing - I'm not sure if we have to change anything on that
interface to skip those RAMBlocks.
Dave
> Cheers,
> Edgar
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/17
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Edgar E. Iglesias, 2017/07/17
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/20
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/20
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/20
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Peter Maydell, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, KONRAD Frederic, 2017/07/21
- Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request, Dr. David Alan Gilbert, 2017/07/21