diff mbox series

[2/3] tools/libxc: change xc_memshr_fork_reset API to match hypervisor

Message ID f3fdd4e99892549dc68e7511f2d84f51af446e86.1651073086.git.tamas.lengyel@intel.com (mailing list archive)
State New, archived
Headers show
Series [1/3] x86/mem_sharing: make fork_reset more configurable | expand

Commit Message

Tamas K Lengyel April 27, 2022, 3:34 p.m. UTC
Need to separately specify if the reset is for the memory or for the VM state,
or both.

Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
---
v5: split from the hypervisor-side patch
---
 tools/include/xenctrl.h     | 3 ++-
 tools/libs/ctrl/xc_memshr.c | 7 ++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

Comments

Tamas K Lengyel May 4, 2022, 1:10 p.m. UTC | #1
On Wed, Apr 27, 2022 at 11:52 AM Tamas K Lengyel
<tamas.lengyel@intel.com> wrote:
>
> Need to separately specify if the reset is for the memory or for the VM state,
> or both.
>
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
> v5: split from the hypervisor-side patch

Patch ping. Could a toolstack maintainer please take a look at this?
The hypervisor side is already merged.

Thanks,
Tamas
Roger Pau Monné May 5, 2022, 8:17 a.m. UTC | #2
On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
> Need to separately specify if the reset is for the memory or for the VM state,
> or both.
> 
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.
Tamas K Lengyel May 12, 2022, 1:46 p.m. UTC | #3
On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>
> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
> > Need to separately specify if the reset is for the memory or for the VM state,
> > or both.
> >
> > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Patch ping. Can this patch be merged please?

Thanks,
Tamas
Tamas K Lengyel May 18, 2022, 3:01 p.m. UTC | #4
On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
<tamas.k.lengyel@gmail.com> wrote:
>
> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >
> > On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
> > > Need to separately specify if the reset is for the memory or for the VM state,
> > > or both.
> > >
> > > Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> >
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Patch ping. Can this patch be merged please?

Patch ping.

Tamas
Jan Beulich May 18, 2022, 3:48 p.m. UTC | #5
On 18.05.2022 17:01, Tamas K Lengyel wrote:
> On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
> <tamas.k.lengyel@gmail.com> wrote:
>>
>> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>
>>> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
>>>> Need to separately specify if the reset is for the memory or for the VM state,
>>>> or both.
>>>>
>>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
>>>
>>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>>
>> Patch ping. Can this patch be merged please?
> 
> Patch ping.

Your mail (and I guess also your earlier one) was _To_ Roger, which
is odd since he already did provide R-b. What you're missing is a
tool stack maintainer ack aiui, so it may help if you send your
pings _To_ the respective people.

Jan
Tamas K Lengyel May 18, 2022, 5:03 p.m. UTC | #6
On Wed, May 18, 2022 at 11:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 18.05.2022 17:01, Tamas K Lengyel wrote:
> > On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
> > <tamas.k.lengyel@gmail.com> wrote:
> >>
> >> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
> >>>
> >>> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
> >>>> Need to separately specify if the reset is for the memory or for the VM state,
> >>>> or both.
> >>>>
> >>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> >>>
> >>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> >>
> >> Patch ping. Can this patch be merged please?
> >
> > Patch ping.
>
> Your mail (and I guess also your earlier one) was _To_ Roger, which
> is odd since he already did provide R-b. What you're missing is a
> tool stack maintainer ack aiui, so it may help if you send your
> pings _To_ the respective people.

True, but all the toolstack maintainers have been CC-d from the start.
Is it the case that CC-ing is now officially insufficient? What's the
point of ./scripts/add_maintainers.pl then which specifically adds
maintainers only as CC? How are you supposed to get their attention?
Just know you specifically have to send emails to them and not the
mailinglist? I'm getting the distinct impression that the toolstack
side has simply become unmaintained/orphaned with no one left who
actually is looking at the mailinglist.

Tamas
Jan Beulich May 19, 2022, 6:03 a.m. UTC | #7
On 18.05.2022 19:03, Tamas K Lengyel wrote:
> On Wed, May 18, 2022 at 11:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 18.05.2022 17:01, Tamas K Lengyel wrote:
>>> On Thu, May 12, 2022 at 9:46 AM Tamas K Lengyel
>>> <tamas.k.lengyel@gmail.com> wrote:
>>>>
>>>> On Thu, May 5, 2022 at 4:27 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>>>>>
>>>>> On Wed, Apr 27, 2022 at 11:34:19AM -0400, Tamas K Lengyel wrote:
>>>>>> Need to separately specify if the reset is for the memory or for the VM state,
>>>>>> or both.
>>>>>>
>>>>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
>>>>>
>>>>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>
>>>> Patch ping. Can this patch be merged please?
>>>
>>> Patch ping.
>>
>> Your mail (and I guess also your earlier one) was _To_ Roger, which
>> is odd since he already did provide R-b. What you're missing is a
>> tool stack maintainer ack aiui, so it may help if you send your
>> pings _To_ the respective people.
> 
> True, but all the toolstack maintainers have been CC-d from the start.
> Is it the case that CC-ing is now officially insufficient?

No - patch submissions should still only Cc maintainers. But I think
pings, especially repeated ones, would better go To the respective
people. (And this follows my general remark I keep making every once
in a while: There's a reason there is both To and Cc, and using them
appropriately can help. Of course there's no guarantee, as people
may not pay attention at all.)

> What's the
> point of ./scripts/add_maintainers.pl then which specifically adds
> maintainers only as CC? How are you supposed to get their attention?
> Just know you specifically have to send emails to them and not the
> mailinglist? I'm getting the distinct impression that the toolstack
> side has simply become unmaintained/orphaned with no one left who
> actually is looking at the mailinglist.

While things are far from ideal (and as you likely know we're still
looking for a 2nd tool stack maintainer), I have actually got the
impression that things have improved a little lately.

Jan
diff mbox series

Patch

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 95bd5eca67..1b089a2c02 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2290,7 +2290,8 @@  int xc_memshr_fork(xc_interface *xch,
  *
  * With VMs that have a lot of memory this call may block for a long time.
  */
-int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain,
+                         bool reset_state, bool reset_memory);
 
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
diff --git a/tools/libs/ctrl/xc_memshr.c b/tools/libs/ctrl/xc_memshr.c
index a6cfd7dccf..a0d0b894e2 100644
--- a/tools/libs/ctrl/xc_memshr.c
+++ b/tools/libs/ctrl/xc_memshr.c
@@ -257,12 +257,17 @@  int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid,
     return xc_memshr_memop(xch, domid, &mso);
 }
 
-int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid, bool reset_state,
+                         bool reset_memory)
 {
     xen_mem_sharing_op_t mso;
 
     memset(&mso, 0, sizeof(mso));
     mso.op = XENMEM_sharing_op_fork_reset;
+    if ( reset_state )
+        mso.u.fork.flags |= XENMEM_FORK_RESET_STATE;
+    if ( reset_memory )
+        mso.u.fork.flags |= XENMEM_FORK_RESET_MEMORY;
 
     return xc_memshr_memop(xch, domid, &mso);
 }