qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Shannon Zhao <zhaoshenglong@huawei.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Auger Eric <eric.auger@redhat.com>
Cc: Shannon Zhao <shannon.zhaosl@gmail.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH V3 2/2] arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR
Date: Fri, 25 May 2018 16:42:33 +0800	[thread overview]
Message-ID: <5B07CC79.1070905@huawei.com> (raw)
In-Reply-To: <CAFEAcA9oCppg2C32vd3YKKmvfO7n1KnFeXG14CV7UHcZpxcTqA@mail.gmail.com>



On 2018/5/24 22:56, Peter Maydell wrote:
> On 24 May 2018 at 15:40, Auger Eric <eric.auger@redhat.com> wrote:
>> > Hi Peter,
>> >
>> > On 05/24/2018 04:16 PM, Peter Maydell wrote:
>>> >> Only for KVM, not for TCG, and it's the other way round: we
>>> >> end up with two lots of PPI/SGI space in the data structure
>>> >> by mistake. Let me fish out the comment I made on the v2 of this
>>> >> series:
>>> >>
>>> >> In the code in master, we have QEMU data structures
>>> >> (bitmaps, etc) which have one entry for each of GICV3_MAXIRQ
>>> >> irqs. That includes the RAZ/WI unused space for the SPIs/PPIs, so
>>> >> for a 1-bit-per-irq bitmap:
>>> >>  [0x00000000, irq 32, irq 33, .... ]
>>> >>
>>> >> When we fill in the values from KVM into these data structures,
>>> >> we start after the unused space, because the for_each_dist_irq_reg()
>>> >> macro starts with _irq = GIC_INTERNAL. But we forgot to adjust
>>> >> the offset value we use for the KVM access, so we start by
>>> >> reading the RAZ/WI values from KVM, and the data structure
>>> >> contents end up with:
>>> >>  [0x00000000, 0x00000000, irq 32, irq 33, ... ]
>>> >> (and the last irqs wouldn't get transferred).
>> > In kvm_dist_get_priority (new code), the offset is where we read and
>> > field is where we write, correct? Offset was shifted so we effectively
>> > read in KVM regs the num_irq-32 SPI states now but don't we start
>> > writing at the beginning of bmp, (ie s->gicd_ipriority), at PPI/SGI
>> > offset? What am I missing?
> Oops, yes, you're right. My explanation applies to the
> various other bitmaps, where we are accessing the
> fields in the data structure using gic_bmp_ptr32(bmp, irq),
> but not to gicd_ipriority[], which we are directly accessing
> starting with the first word, not by indexing via bmp[irq].
> 
> So we need to handle these two cases differently.
> You're correct that for gicd_ipriority[], the code in
> master reads and writes to that data structure as:
>  [0, 0, ..., 0, irq 32, irq 33, ..., 0, 0, ... 0]
> so all the values are in the right place but we:
>  (a) unnecessarily read/write zeroes for the PPI/SGI fields
>  (b) fail to transfer the last 32 interrupts
> 
> We can fix the gicd_ipriority[] case simply by adding
>    bmp = GIC_INTERNAL;
> before the assignment to 'field' in both kvm_dist_get_priority()
> and kvm_dist_put_priority(). This doesn't affect migration
> compatibility. We should do this separately from fixing the
> other bitmaps, because it's simpler.
> 
If we do bmp += GIC_INTERNAL, we should also add this to offset,
otherwise we will put the SGI/PPIs data to SPIs, right?

Thanks,
-- 
Shannon

  parent reply	other threads:[~2018-05-25  8:43 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-23  3:53 [Qemu-devel] [PATCH V3 1/2] arm_gicv3_kvm: increase clroffset accordingly Shannon Zhao
2018-05-23  3:53 ` [Qemu-devel] [PATCH V3 2/2] arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR Shannon Zhao
2018-05-24  9:04   ` Auger Eric
2018-05-24  9:20     ` Shannon Zhao
2018-05-24 12:10       ` Auger Eric
2018-05-24 13:14     ` Peter Maydell
2018-05-24 13:59       ` Auger Eric
2018-05-24 14:16         ` Peter Maydell
2018-05-24 14:40           ` Auger Eric
2018-05-24 14:56             ` Peter Maydell
2018-05-24 14:58               ` Peter Maydell
2018-05-24 15:09               ` Auger Eric
2018-05-25  8:42               ` Shannon Zhao [this message]
2018-05-25  9:00                 ` Peter Maydell
2018-05-24 13:11   ` Peter Maydell
2018-05-25  9:15     ` Shannon Zhao
2018-05-24 12:38 ` [Qemu-devel] [PATCH V3 1/2] arm_gicv3_kvm: increase clroffset accordingly Peter Maydell

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=5B07CC79.1070905@huawei.com \
    --to=zhaoshenglong@huawei.com \
    --cc=eric.auger@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shannon.zhaosl@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).