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

Re: [Xen-devel] [PATCH v2 3/3] hvm_has_dm: Do a full check for backing DM



On 02/06/15 02:35, Jan Beulich wrote:
>>>> On 05.02.15 at 20:02, <dslutz@xxxxxxxxxxx> wrote:
>> On 02/03/15 09:58, Jan Beulich wrote:
>>>>>> On 02.02.15 at 16:22, <dslutz@xxxxxxxxxxx> wrote:
>> Ok, will be working on a much better commit message.  Do you want the
>> new commit message copied here (in the summary of the changes), or just
>> that fact that there is a new commit message?
> 
> Only mention it there.
> 

Ok

>>>> --- a/xen/arch/x86/hvm/emulate.c
>>>> +++ b/xen/arch/x86/hvm/emulate.c
>>>> @@ -218,8 +218,11 @@ static int hvmemul_do_io(
>>>>              vio->io_state = HVMIO_handle_mmio_awaiting_completion;
>>>>          break;
>>>>      case X86EMUL_UNHANDLEABLE:
>>>> +    {
>>>> +        struct hvm_ioreq_server *s = hvm_has_dm(curr->domain, &p);
>>>> +
>>>>          /* If there is no backing DM, just ignore accesses */
>>>> -        if ( !hvm_has_dm(curr->domain) )
>>>> +        if ( !s )
>>>>          {
>>>>              rc = X86EMUL_OKAY;
>>>>              vio->io_state = HVMIO_none;
>>>
>>> You alter the flow here, but leave the (now stale) comment
>>> untouched - !hvm_has_dm() no longer has the original meaning.
>>>
>>
>> I will say that the comment is not stale. Also this code flow change
>> is what I am trying to do in this patch.  Since I am talking about
>> Paul's code also, I might be off base.
>>
>> It is true that hvm_has_dm() has changed.  However the change
>> is from "there is no backing DM" to "there is no backing DM
>> that will process this request".  To me they mean the same thing.
>>
>> That is why I did not change the name and did not see a need
>> to change the comment.  However I can adjust the comment to be much longer.
>>
>> How does:
>>
>> /*
>>  * If there is no backing DM, or there is no backing DM to handle
>>  * this request, act just like a missing device.
>>  */
>>
>> look as a new comment?
> 
> Simply inserting "suitable" into the original comment would do imo.
> 

Will change to:

/* If there is no suitable backing DM, just ignore accesses */


>> Would it help to s/hvm_has_dm/hvm_has_dm_for_req/?
> 
> No, not really. But see also below for the name.
> 

ok

>> Here is the proposed new commit message:
> 
> Looks a lot better.
> 
>> The key part of skipping the retry is to do "rc = X86EMUL_OKAY"
>> which is what the error path on the call to hvm_has_dm() does in
>> hvmemul_do_io() (the only call on hvm_has_dm()).
>>
>> Since this case is no longer handled in hvm_send_assist_req(), move
>> the call to hvm_complete_assist_req() into hvm_has_dm().
>>
>> As part of this change, do the work of hvm_complete_assist_req() in
>> the PVH case.  Acting more like real hardware looks to be better.
>>
>> Since there is only one caller of hvm_complete_assist_req(), fold
>> that routine into the changed hvm_has_dm().
> 
> As said before, with the current name it's not reasonable for the
> function to also complete the request (the name strictly suggests
> a "read-only" operation). But as it looks this one has only a single
> caller too, so maybe apart from renaming an alternative might
> again be to fold it into that single caller?
> 

I think that folding routines between files is not the way I would
normally go.  So how about not folding hvm_complete_assist_req()
anywhere, just change it to return void.  Drop the routine
hvm_has_dm(), and have hvmemul_do_io() call hvm_select_ioreq_server()
and in the error path call hvm_complete_assist_req().  This does
leave only one caller of hvm_complete_assist_req(), but the code blocks
are not changing files.  Here is the diff in hvmemul_do_io() to match
these words:

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -218,21 +218,27 @@ static int hvmemul_do_io(
             vio->io_state = HVMIO_handle_mmio_awaiting_completion;
         break;
     case X86EMUL_UNHANDLEABLE:
-        /* If there is no backing DM, just ignore accesses */
-        if ( !hvm_has_dm(curr->domain) )
+    {
+        struct hvm_ioreq_server *s =
+            hvm_select_ioreq_server(curr->domain, &p);
+
+        /* If there is no suitable backing DM, just ignore accesses */
+        if ( !s )
         {
+            hvm_complete_assist_req(&p);
             rc = X86EMUL_OKAY;
             vio->io_state = HVMIO_none;
         }
         else


>> Adding "rc = X86EMUL_OKAY" in the failing case of
>> hvm_send_assist_req() would unfix what was done in commit
>> bac0999325056a3b3a92f7622df7ffbc5388b1c3 and commit
>> f20f3c8ece5c10fa7626f253d28f570a43b23208.  We are currently doing
>> the succeeding case of hvm_send_assist_req() and retying the I/O.
> 
> Maybe s/unfix/break/ ?
> 

Yes.

   -Don Slutz

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.