Re: [virt-manager] [PATCH 0/7] Add a checkbox in memory details to control memory access mode

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


On 8/1/21 8:36 AM, Lin Ma wrote:
> Future patches about virtiofs addhw support relies on shared memory access.
> Lin Ma (7):
>   domcapabilities: Get filesystem devices
>   domcapabilities: Add supports_filesystem_virtiofs()
>   domcapabilities: Add supports_memorybacking_memfd()
>   domain: memorybacking: Add function is_shared_access()
>   domain: cpu: Add function has_private_memAccess_cells()
>   domain: cpu: Add function all_shared_memAccess_cells()
>   details: Add new checkbox to control shared memory access
>  ui/details.ui                    | 14 +++++++++
>  virtManager/details/   | 52 ++++++++++++++++++++++++++++++++
>  virtManager/object/     | 17 ++++++++++-
>  virtinst/domain/           | 14 +++++++++
>  virtinst/domain/ |  3 ++
>  virtinst/      | 20 ++++++++++++
>  6 files changed, 119 insertions(+), 1 deletion(-)

Sorry for the reaaally long delay. This came in right when I went on
paternity leave and I'm still digging out of the backlog.

I've pushed this series now, but with some bits removed. I stripped the
logic back to only handle enabling+disabling source_type=memfd and
access_mode=shared. If the guest has numa cells configured, we leave the
checkbox unchecked and disable it with a warning. Same thing if the
domcaps don't advertise both virtiofs and memfd.

I think that logic covers what most users will need, going forward. If a
user has <numa> in their XML, I think they can be expected to make the
shared memory change themselves. It makes me a little nervous getting
into the business of processing <numa> XML that virt-manager otherwise
doesn't have any UI for. So my preference is to not do that.

If you have a good argument for why it should be readded, I'm open to
it. But resubmitting it should come with uitests, since this adds some
annoying corner cases that I will want to see tested. FWIW I tried to
keep the code revert to a single commit, so hopefully it's easy to
revive, if you are interested.

The other big thing I did was move the logic from to, which will make it easier to share the interesting bits with
the Add Hardware UI like I mentioned in this mail:

I'm working towards a release, so unless you have patches with that work
kicking around in a git branch, I'll make the addhw change in the next
few weeks.


[Index of Archives]     [Linux Virtualization]     [KVM Development]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux