| Message ID | 1569245722-23375-1-git-send-email-alexandru.elisei@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm: Allow the user to define the memory layout | expand |
On Mon, Sep 23, 2019 at 02:35:06PM +0100, Alexandru Elisei wrote: > The guest memory layout created by kvmtool is fixed: regular MMIO is below > 1G, PCI MMIO is below 2G, and the RAM always starts at the 2G mark. Real > hardware can have a different memory layout, and being able to create a > specific memory layout can be very useful for testing the guest kernel. > > This series allows the user the specify the memory layout for the > virtual machine by expanding the -m/--mem option to take an <addr> > parameter, and by adding architecture specific options to define the I/O > ports, regular MMIO and PCI MMIO memory regions. > > The user defined memory regions are implemented in patch #16; I consider > the patch to be an RFC because I'm not really sure that my approach is the > correct one; for example, I decided to make the options arch dependent > because that seemed like the path of least resistance, but they could have > just as easily implemented as arch independent and each architecture > advertised having support for them via a define (like with RAM base > address). Do you plan to repost this with Andre's comments addressed? Will
Hi, On 2/5/20 5:16 PM, Will Deacon wrote: > On Mon, Sep 23, 2019 at 02:35:06PM +0100, Alexandru Elisei wrote: >> The guest memory layout created by kvmtool is fixed: regular MMIO is below >> 1G, PCI MMIO is below 2G, and the RAM always starts at the 2G mark. Real >> hardware can have a different memory layout, and being able to create a >> specific memory layout can be very useful for testing the guest kernel. >> >> This series allows the user the specify the memory layout for the >> virtual machine by expanding the -m/--mem option to take an <addr> >> parameter, and by adding architecture specific options to define the I/O >> ports, regular MMIO and PCI MMIO memory regions. >> >> The user defined memory regions are implemented in patch #16; I consider >> the patch to be an RFC because I'm not really sure that my approach is the >> correct one; for example, I decided to make the options arch dependent >> because that seemed like the path of least resistance, but they could have >> just as easily implemented as arch independent and each architecture >> advertised having support for them via a define (like with RAM base >> address). > Do you plan to repost this with Andre's comments addressed? The series will conflict with my other series which add support for assignable BARs and PCIE. I am definitely still interested in reposting this because I think it's very useful, and I'll do it after the other patches get merged. Thank you for taking a look! Thanks, Alex > > Will
On 2020-02-05 17:18, Alexandru Elisei wrote: > Hi, > > On 2/5/20 5:16 PM, Will Deacon wrote: >> On Mon, Sep 23, 2019 at 02:35:06PM +0100, Alexandru Elisei wrote: >>> The guest memory layout created by kvmtool is fixed: regular MMIO is >>> below >>> 1G, PCI MMIO is below 2G, and the RAM always starts at the 2G mark. >>> Real >>> hardware can have a different memory layout, and being able to create >>> a >>> specific memory layout can be very useful for testing the guest >>> kernel. >>> >>> This series allows the user the specify the memory layout for the >>> virtual machine by expanding the -m/--mem option to take an <addr> >>> parameter, and by adding architecture specific options to define the >>> I/O >>> ports, regular MMIO and PCI MMIO memory regions. >>> >>> The user defined memory regions are implemented in patch #16; I >>> consider >>> the patch to be an RFC because I'm not really sure that my approach >>> is the >>> correct one; for example, I decided to make the options arch >>> dependent >>> because that seemed like the path of least resistance, but they could >>> have >>> just as easily implemented as arch independent and each architecture >>> advertised having support for them via a define (like with RAM base >>> address). >> Do you plan to repost this with Andre's comments addressed? > > The series will conflict with my other series which add support for > assignable > BARs and PCIE. I am definitely still interested in reposting this > because I think > it's very useful, and I'll do it after the other patches get merged. I'd be happy to review the rebased version. I definitely need it to support some of my most funky HW... M.