From: Christoffer Dall <cdall@linaro.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu,
wu.wubin@huawei.com, andre.przywara@arm.com
Subject: Re: [RFC PATCH 3/3] kvm: arm/arm64: vgic-its: fix return value for restore
Date: Wed, 13 Sep 2017 22:35:16 -0700 [thread overview]
Message-ID: <20170914053516.GO1631@lvm> (raw)
In-Reply-To: <6246fa89-50cb-488a-008c-1290ced290e7@redhat.com>
On Wed, Sep 13, 2017 at 11:25:01PM +0200, Auger Eric wrote:
> Hi,
>
> On 13/09/2017 22:02, Christoffer Dall wrote:
> > Hi Eric,
> >
> > On Wed, Sep 06, 2017 at 05:18:35PM +0200, Auger Eric wrote:
> >> Hi Wanghaibin,
> >>
> >> On 06/09/2017 15:05, wanghaibin wrote:
> >>> This patch fix the migrate restore tables failure.
> >>>
> >>> The same scene, at the destination, the restore tables interface traversal guest
> >>> memory, and check the dte/ite is valid or not.
> >>> If all dtes/ites are invalid, we will do try next one, and the last it will take
> >>> the 1 return value, but currently, it be treated as error. That's not correct.
> >> There's indeed a bug here! In case all entries are invalid we shouldn't
> >> return an error.
> >>
> >> One solution could be to relax the error checking in scan_its_table()
> >> and do not return 1 when the whole length has been scanned. This would
> >> fix your issue.
> If you do not return 1 in scan_its_table if the whole size has been
> scanned, you achieve the same thing as in this patch and you simplify
> the error handling.
Yes, but then you have to rework the scan function otherwise to work
with indirect tables, and I'm not sure that becomes more pretty.
> >>
> >> drawback of that change:
> >> at the moment we check the consistency of the entry data (next offset
> >> field). At the moment if the next_offset points to an entry outside of
> >> the table scope we are able to return an error (for top level tables).
> >>
> >> Otherwise, if we want to keep that check, I think we would need to add a
> >> bool *valid parameter to entry_fn_t. in scan_its_table() we would return
> >> 1 only if last fn() call returns valid and len <= 0.
> >>
> >
> > I don't really understand what you're proposing.
> The above method or Wanghaibin's patch removes a consistency check on
> the entry next offset field. But maybe this is better to drop it and
> have a code that gains in readability.
>
Can you show me an alternative better patch and we can compare?
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-09-14 5:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 13:05 [RFC PATCH 0/3] fix migrate failed when vm is in booting wanghaibin
2017-09-06 13:05 ` [RFC PATCH 1/3] kvm: arm/arm64: vgic-vits: separate vgic_its_free_list() function wanghaibin
2017-09-12 8:50 ` wanghaibin
2017-09-12 10:08 ` Auger Eric
2017-09-13 19:13 ` Christoffer Dall
2017-09-13 19:14 ` Christoffer Dall
2017-09-16 1:59 ` wanghaibin
2017-09-16 22:17 ` Christoffer Dall
2017-09-06 13:05 ` [RFC PATCH 2/3] kvm: arm/arm64: vgic-vits: free its resource when vm reboot/reset wanghaibin
2017-09-06 16:20 ` Auger Eric
2017-09-07 1:32 ` wanghaibin
2017-09-07 11:28 ` Auger Eric
2017-09-10 18:46 ` Auger Eric
2017-09-12 11:15 ` wanghaibin
2017-09-13 8:49 ` Auger Eric
2017-09-13 19:34 ` Christoffer Dall
2017-09-13 21:13 ` Auger Eric
2017-09-14 5:34 ` Christoffer Dall
2017-09-06 13:05 ` [RFC PATCH 3/3] kvm: arm/arm64: vgic-its: fix return value for restore wanghaibin
2017-09-06 15:18 ` Auger Eric
2017-09-13 20:02 ` Christoffer Dall
2017-09-13 21:25 ` Auger Eric
2017-09-14 5:35 ` Christoffer Dall [this message]
2017-09-13 20:04 ` Christoffer Dall
2017-09-14 8:30 ` Auger Eric
2017-09-16 2:02 ` wanghaibin
2017-09-20 1:57 ` [RFC PATCH 0/3] fix migrate failed when vm is in booting wanghaibin
2017-09-20 7:16 ` Auger Eric
2017-09-21 12:17 ` wanghaibin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170914053516.GO1631@lvm \
--to=cdall@linaro.org \
--cc=andre.przywara@arm.com \
--cc=eric.auger@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=wu.wubin@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.