[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 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. >>> --- 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. > Would it help to s/hvm_has_dm/hvm_has_dm_for_req/? No, not really. But see also below for the name. > 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? > 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/ ? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |