[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v6 2/4] x86/hvm: Treat non-instruction fetch nested page faults also as read violations
- To: "Tamas Lengyel" <tamas.lengyel@xxxxxxxxxxxx>
- From: "Jan Beulich" <JBeulich@xxxxxxxx>
- Date: Fri, 15 Aug 2014 17:48:55 +0100
- Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, "ian.campbell@xxxxxxxxxx" <ian.campbell@xxxxxxxxxx>, "stefano.stabellini@xxxxxxxxxxxxx" <stefano.stabellini@xxxxxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "ian.jackson@xxxxxxxxxxxxx" <ian.jackson@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>, Eddie Dong <eddie.dong@xxxxxxxxx>, "Aravind.Gopalakrishnan@xxxxxxx" <Aravind.Gopalakrishnan@xxxxxxx>, "suravee.suthikulpanit@xxxxxxx" <suravee.suthikulpanit@xxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Delivery-date: Fri, 15 Aug 2014 16:49:19 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
>>> On 15.08.14 at 18:33, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>>
>>
>>>> Ah, no, clearly not: Again - read-modify-write instructions _have_
>>> to be reported as being reads and writes. Reporting simply writes
>>> as reads too is the smaller of the two "evils" here. If anything we
>>> could introduce a "maybe-read" flag that gets set when don't know
>>> for sure.
>>>
>>
>> I think an explicit comment in VMX and SVM code explaining why the bits
>> are set the way they are may be sufficient (I know this is mentioned in the
>> commit message but having it in the code is better IMO).
>
> I can certainly do that if the consensus is to include the patch.
The patch is a necessary prerequisite for the patch that I sent you
earlier (which I'll rebase on top of yours as soon as yours reached a
state that can go in - which, afaic, is already the case), so it will
have to go in (as said in another reply, in the worst case with a
maybe-read flag instead of the current solution, but personally I
don't see a point to distinguish the two cases until a consumer
appears that can't tolerate plain writes to also be marked as being
reads).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|