lkml.org 
[lkml]   [2017]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
    On 11/15/2017 09:26 PM, Michael S. Tsirkin wrote:
    > On Wed, Nov 15, 2017 at 11:47:58AM +0800, Wei Wang wrote:
    >> On 11/15/2017 05:21 AM, Michael S. Tsirkin wrote:
    >>> On Tue, Nov 14, 2017 at 08:02:03PM +0800, Wei Wang wrote:
    >>>> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
    >>>>>> - guest2host_cmd: written by the guest to ACK to the host about the
    >>>>>> commands that have been received. The host will clear the corresponding
    >>>>>> bits on the host2guest_cmd register. The guest also uses this register
    >>>>>> to send commands to the host (e.g. when finish free page reporting).
    >>>>> I am not sure what is the role of guest2host_cmd. Reporting of
    >>>>> the correct cmd id seems sufficient indication that guest
    >>>>> received the start command. Not getting any more seems sufficient
    >>>>> to detect stop.
    >>>>>
    >>>> I think the issue is when the host is waiting for the guest to report pages,
    >>>> it does not know whether the guest is going to report more or the report is
    >>>> done already. That's why we need a way to let the guest tell the host "the
    >>>> report is done, don't wait for more", then the host continues to the next
    >>>> step - sending the non-free pages to the destination. The following method
    >>>> is a conclusion of other comments, with some new thought. Please have a
    >>>> check if it is good.
    >>> config won't work well for this IMHO.
    >>> Writes to config register are hard to synchronize with the VQ.
    >>> For example, guest sends free pages, host says stop, meanwhile
    >>> guest sends stop for 1st set of pages.
    >> I still don't see an issue with this. Please see below:
    >> (before jumping into the discussion, just make sure I've well explained this
    >> point: now host-to-guest commands are done via config, and guest-to-host
    >> commands are done via the free page vq)
    > This is fine by me actually. But right now you have guest to host
    > not going through vq, going through command register instead -
    > this is how sending stop to host seems to happen.
    > If you make it go through vq then I think all will be well.
    >
    >> Case: Host starts to request the reporting with cmd_id=1. Some time later,
    >> Host writes "stop" to config, meantime guest happens to finish the reporting
    >> and plan to actively send a "stop" command from the free_page_vq().
    >> Essentially, this is like a sync between two threads - if we view
    >> the config interrupt handler as one thread, another is the free page
    >> reporting worker thread.
    >>
    >> - what the config handler does is simply:
    >> 1.1: WRITE_ONCE(vb->reporting_stop, true);
    >>
    >> - what the reporting thread will do is
    >> 2.1: WRITE_ONCE(vb->reporting_stop, true);
    >> 2.2: send_stop_to_host_via_vq();
    >>
    >> From the guest point of view, no matter 1.1 is executed first or 2.1 first,
    >> it doesn't make a difference to the end result - vb->reporting_stop is set.
    >>
    >> From the host point of view, it knows that cmd_id=1 has truly stopped the
    >> reporting when it receives a "stop" sign via the vq.
    >>
    >>
    >>> How about adding a buffer with "stop" in the VQ instead?
    >>> Wastes a VQ entry which you will need to reserve for this
    >>> but is it a big deal?
    >> The free page vq is guest-to-host direction.
    > Yes, for guest to host stop sign.
    >
    >> Using it for host-to-guest
    >> requests will make it bidirectional, which will result in the same issue
    >> described before: https://lkml.org/lkml/2017/10/11/1009 (the first response)
    >>
    >> On the other hand, I think adding another new vq for host-to-guest
    >> requesting doesn't make a difference in essence, compared to using config
    >> (same 1.1, 2.1, 2.2 above), but will be more complicated.
    > I agree with this. Host to guest can just incremenent the "free command id"
    > register.


    OK, thanks for the suggestions. I think one more issue left here:

    Previously, when the guest receives a config interrupt, it blindly adds
    the balloon work item to the workqueue in virtballoon_changed(), because
    only ballooning uses the config.
    Now, free page reporting is requested via config, too.

    We have the following two options:

    Option 1: add "diff = towards_target()" to virtballoon_changed(), and if
    diff = 0, it will not add the balloon work item to the wq.

    Option 2: add "cmd" for the host-to-guest request, and add the item when
    "cmd | CMD_BALLOON" is true.

    I'm inclined to take option 1 now. Which one would you prefer?

    Best,
    Wei


    \
     
     \ /
      Last update: 2017-11-17 17:17    [W:2.243 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site