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

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range


  • To: Julien Grall <julien.grall.oss@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: André Przywara <andre.przywara@xxxxxxx>
  • Date: Wed, 13 Nov 2019 01:58:57 +0000
  • Autocrypt: addr=andre.przywara@xxxxxxx; prefer-encrypt=mutual; keydata= xsFNBFNPCKMBEAC+6GVcuP9ri8r+gg2fHZDedOmFRZPtcrMMF2Cx6KrTUT0YEISsqPoJTKld tPfEG0KnRL9CWvftyHseWTnU2Gi7hKNwhRkC0oBL5Er2hhNpoi8x4VcsxQ6bHG5/dA7ctvL6 kYvKAZw4X2Y3GTbAZIOLf+leNPiF9175S8pvqMPi0qu67RWZD5H/uT/TfLpvmmOlRzNiXMBm kGvewkBpL3R2clHquv7pB6KLoY3uvjFhZfEedqSqTwBVu/JVZZO7tvYCJPfyY5JG9+BjPmr+ REe2gS6w/4DJ4D8oMWKoY3r6ZpHx3YS2hWZFUYiCYovPxfj5+bOr78sg3JleEd0OB0yYtzTT esiNlQpCo0oOevwHR+jUiaZevM4xCyt23L2G+euzdRsUZcK/M6qYf41Dy6Afqa+PxgMEiDto ITEH3Dv+zfzwdeqCuNU0VOGrQZs/vrKOUmU/QDlYL7G8OIg5Ekheq4N+Ay+3EYCROXkstQnf YYxRn5F1oeVeqoh1LgGH7YN9H9LeIajwBD8OgiZDVsmb67DdF6EQtklH0ycBcVodG1zTCfqM AavYMfhldNMBg4vaLh0cJ/3ZXZNIyDlV372GmxSJJiidxDm7E1PkgdfCnHk+pD8YeITmSNyb 7qeU08Hqqh4ui8SSeUp7+yie9zBhJB5vVBJoO5D0MikZAODIDwARAQABzS1BbmRyZSBQcnp5 d2FyYSAoQVJNKSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT7CwXsEEwECACUCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJTWSV8AhkBAAoJEAL1yD+ydue63REP/1tPqTo/f6StS00g NTUpjgVqxgsPWYWwSLkgkaUZn2z9Edv86BLpqTY8OBQZ19EUwfNehcnvR+Olw+7wxNnatyxo D2FG0paTia1SjxaJ8Nx3e85jy6l7N2AQrTCFCtFN9lp8Pc0LVBpSbjmP+Peh5Mi7gtCBNkpz KShEaJE25a/+rnIrIXzJHrsbC2GwcssAF3bd03iU41J1gMTalB6HCtQUwgqSsbG8MsR/IwHW XruOnVp0GQRJwlw07e9T3PKTLj3LWsAPe0LHm5W1Q+euoCLsZfYwr7phQ19HAxSCu8hzp43u zSw0+sEQsO+9wz2nGDgQCGepCcJR1lygVn2zwRTQKbq7Hjs+IWZ0gN2nDajScuR1RsxTE4WR lj0+Ne6VrAmPiW6QqRhliDO+e82riI75ywSWrJb9TQw0+UkIQ2DlNr0u0TwCUTcQNN6aKnru ouVt3qoRlcD5MuRhLH+ttAcmNITMg7GQ6RQajWrSKuKFrt6iuDbjgO2cnaTrLbNBBKPTG4oF D6kX8Zea0KvVBagBsaC1CDTDQQMxYBPDBSlqYCb/b2x7KHTvTAHUBSsBRL6MKz8wwruDodTM 4E4ToV9URl4aE/msBZ4GLTtEmUHBh4/AYwk6ACYByYKyx5r3PDG0iHnJ8bV0OeyQ9ujfgBBP B2t4oASNnIOeGEEcQ2rjzsFNBFNPCKMBEACm7Xqafb1Dp1nDl06aw/3O9ixWsGMv1Uhfd2B6 it6wh1HDCn9HpekgouR2HLMvdd3Y//GG89irEasjzENZPsK82PS0bvkxxIHRFm0pikF4ljIb 6tca2sxFr/H7CCtWYZjZzPgnOPtnagN0qVVyEM7L5f7KjGb1/o5EDkVR2SVSSjrlmNdTL2Rd zaPqrBoxuR/y/n856deWqS1ZssOpqwKhxT1IVlF6S47CjFJ3+fiHNjkljLfxzDyQXwXCNoZn BKcW9PvAMf6W1DGASoXtsMg4HHzZ5fW+vnjzvWiC4pXrcP7Ivfxx5pB+nGiOfOY+/VSUlW/9 GdzPlOIc1bGyKc6tGREH5lErmeoJZ5k7E9cMJx+xzuDItvnZbf6RuH5fg3QsljQy8jLlr4S6 8YwxlObySJ5K+suPRzZOG2+kq77RJVqAgZXp3Zdvdaov4a5J3H8pxzjj0yZ2JZlndM4X7Msr P5tfxy1WvV4Km6QeFAsjcF5gM+wWl+mf2qrlp3dRwniG1vkLsnQugQ4oNUrx0ahwOSm9p6kM CIiTITo+W7O9KEE9XCb4vV0ejmLlgdDV8ASVUekeTJkmRIBnz0fa4pa1vbtZoi6/LlIdAEEt PY6p3hgkLLtr2GRodOW/Y3vPRd9+rJHq/tLIfwc58ZhQKmRcgrhtlnuTGTmyUqGSiMNfpwAR AQABwsFfBBgBAgAJBQJTTwijAhsMAAoJEAL1yD+ydue64BgP/33QKczgAvSdj9XTC14wZCGE U8ygZwkkyNf021iNMj+o0dpLU48PIhHIMTXlM2aiiZlPWgKVlDRjlYuc9EZqGgbOOuR/pNYA JX9vaqszyE34JzXBL9DBKUuAui8z8GcxRcz49/xtzzP0kH3OQbBIqZWuMRxKEpRptRT0wzBL O31ygf4FRxs68jvPCuZjTGKELIo656/Hmk17cmjoBAJK7JHfqdGkDXk5tneeHCkB411p9WJU vMO2EqsHjobjuFm89hI0pSxlUoiTL0Nuk9Edemjw70W4anGNyaQtBq+qu1RdjUPBvoJec7y/ EXJtoGxq9Y+tmm22xwApSiIOyMwUi9A1iLjQLmngLeUdsHyrEWTbEYHd2sAM2sqKoZRyBDSv ejRvZD6zwkY/9nRqXt02H1quVOP42xlkwOQU6gxm93o/bxd7S5tEA359Sli5gZRaucpNQkwd KLQdCvFdksD270r4jU/rwR2R/Ubi+txfy0dk2wGBjl1xpSf0Lbl/KMR5TQntELfLR4etizLq Xpd2byn96Ivi8C8u9zJruXTueHH8vt7gJ1oax3yKRGU5o2eipCRiKZ0s/T7fvkdq+8beg9ku fDO4SAgJMIl6H5awliCY2zQvLHysS/Wb8QuB09hmhLZ4AifdHyF1J5qeePEhgTA+BaUbiUZf i4aIXCH3Wv6K
  • Cc: Jürgen Groß <jgross@xxxxxxxx>, Peng Fan <peng.fan@xxxxxxx>, "julien.grall@xxxxxxx" <julien.grall@xxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 13 Nov 2019 01:55:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13/11/2019 01:08, Julien Grall wrote:

Hi,

> On Tue, 12 Nov 2019, 04:01 Stefano Stabellini, <sstabellini@xxxxxxxxxx
> <mailto:sstabellini@xxxxxxxxxx>> wrote:
> 
>     On Sat, 9 Nov 2019, Julien Grall wrote:
>     > On Sat, 9 Nov 2019, 04:27 Stefano Stabellini,
>     <sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx>> wrote:
>     >       On Thu, 7 Nov 2019, Peng Fan wrote:
>     >       > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>     >       >
>     >       > Signed-off-by: Peng Fan <peng.fan@xxxxxxx
>     <mailto:peng.fan@xxxxxxx>>
>     >
>     >       Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx
>     <mailto:sstabellini@xxxxxxxxxx>>
>     >
>     >
>     > To be honest, I am not sure the code is correct. A read to those
>     registers should tell you the list of interrupts active. As we always
>     > return 0, this will not return the correct state of the GIC.
>     >
>     > I know that returning the list of actives interrupts is
>     complicated with the old vGIC, but I don't think silently ignoring
>     it is a good
>     > idea.
>     > The question here is why the guest accessed those registers? What
>     is it trying to figure out?
> 
>     We are not going to solve the general problem at this stage. At the
>     moment the code:
> 
>     - ignore the first register only
>     - print an error and return an IO_ABORT error for the other regs
> 
>     For the inconsistency alone the second option is undesirable. Also it
>     doesn't match the write implementation, which does the same thing for
>     all the GICD_ISACTIVER* regs instead of having a special treatment for
>     the first one only. It looks like a typo in the original patch to me.
> 
>     The proposed patch switches the behavior to:
> 
>     - silently ignore all the GICD_ISACTIVER* regs (as proposed)
> 
> 
>     is an improvement.
> 
> 
> Peng mentioned that Linux is accessing it, so the worst thing we can do
> is lying to the guest (as you suggest here). I would definitely not call
> that an improvement.

The ISACTIVER range is wrong in the description, it covers only one
register, not multiple. This is obviously a typo, since it's correct in
both GICv2 and in the high level switch/case in GICv3. Reading from
outside of any range will inject an abort into the guest, which runs in
kernel space. This will probably result in a guest crash. I would
consider not crashing an improvement.

About "lying" to the guest: Typically an IRQ is just active for a very
short time, so 0 is a very good answer, actually. The old VGIC in KVM
did exactly the same:
        vgic_reg_access(mmio, NULL, offset,
                        ACCESS_READ_RAZ | ACCESS_WRITE_IGNORED);

The proper solution would be:
1) Track the state of the active bit when we can observe it, so when the
guest exits with an active IRQ. The new VGIC does that.
2) Kick out all VCPUs that have IRQs in that given rank, and sample the
active bit from the LRs. Sounds pretty horrible, and chances are very
high you will get all 0s there.

So if I compare "fix those two typos and preserve the state that the Xen
VGIC has been in for years" to "create a lot of racy code for a rare
corner case", the first one surely wins.
That doesn't mean we should never try it, but surely this fix needs to
go in meanwhile.

> In the current state, it is a Nack. If there were a warning, then I
> would be more inclined to see this patch going through.

Do you mean a warning that we are about to lie to the guest? That sounds
pretty useless, since nobody can do anything about it. Plus we have
already those warnings on writing to these registers, and this always
confuses people and triggered pointless bug reports.

I think the old VGIC has bigger problems ;-)

Cheers,
Andre

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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