qemu-block
[Top][All Lists]
Advanced

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

Re: [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIM


From: BALATON Zoltan
Subject: Re: [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified
Date: Sat, 2 Jan 2021 15:12:14 +0100 (CET)

On Sat, 2 Jan 2021, Peter Maydell wrote:
On Sat, 2 Jan 2021 at 11:22, BALATON Zoltan <balaton@eik.bme.hu> wrote:
I have similar code in the series I've just posted where I'm mapping
regions of serial devices. I did consider using set_enabled and
set_address but ended up with removing and adding regions because I'm not
sure what happens if guest tries to move one region over another like
having one region at a default location while guest tries to map the other
one there (the pegasos2 maps serial at 0x2f8 which is normally COM2 on a
PC). This should not happen in theory but when removing disabled regions
it cannot happen so that looks safer therefore I chose to do that. Not
sure if this could be a problem here just shared my thughts about this.

I'm not sure what you have in mind -- could you explain further?
There should be no difference as far as the MemoryRegion handling
code is concerned between "this memory region is marked disabled" and
"the memory region was deleted and will be created from fresh and added
back later" -- an MR that's in the hierarchy but not enabled is
entirely ignored, as if it wasn't there at all, when creating the
flat-view.

The device I was implementing has two registers one to set base address of io region and another with bits to enable/disable the regions so I could do set_address for base regs and set_enabled for control reg bits but I've seen guests first flipping the enable bits on then setting the base address so I thought it might cause problems with regions added to their parent but thinking about it more it's probably the same if we remove regions and add them instead of just set_enabled because they should be readded when control reg bits are set so they'll end up at the same default address.

That said, doing memory_region_del_subregion()/memory_region_add_subregion()
I think is also OK -- what's definitely not required is actually
deleting and recreating the MRs the way this code is doing.

Anyway that's what I ended up doing and did not notice that this patch was also deleting and recreating the memory regions which I did not do just removing from parent when they are disabled but using set_address if they are enabled and new base is set. Removing inactive regions maybe better for debugging because they show up in info mtree so one can see which one is enabled/disabled not sure how disabled regions show up though.

All in all I probably have nothing to add to this so just disregard my comment.

Regards,
BALATON Zoltan



reply via email to

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