linux-kernel - Re: [PATCH v3 04/12] Add "handle page fault" PV helper.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B58181B.60405@redhat.com>
Date:	Thu, 21 Jan 2010 11:02:19 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Gleb Natapov <gleb@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, kvm@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, mingo@...e.hu,
	tglx@...utronix.de, riel@...hat.com, cl@...ux-foundation.org
Subject: Re: [PATCH v3 04/12] Add "handle page fault" PV helper.

On 01/20/2010 07:43 PM, H. Peter Anvin wrote:
> On 01/20/2010 02:02 AM, Gleb Natapov wrote:
>>
>>> You can have the guest OS take an exception on a vector above 31 just
>>> fine; you just need it to tell the hypervisor which vector it, the OS,
>>> assigned for this purpose.
>>>
>> VMX doesn't allow to inject hardware exception with vector greater 
>> then 31.
>> SDM 3B section 23.2.1.3.
>>
>
> OK, you're right.  I had missed that... I presume it was done for 
> implementation reasons.

My expectation is that is was done for forward compatibility reasons.

>
>> I can inject the event as HW interrupt on vector greater then 32 but not
>> go through APIC so EOI will not be required. This sounds 
>> non-architectural
>> and I am not sure kernel has entry point code for this kind of event, it
>> has one for exception and one for interrupts that goes through 
>> __do_IRQ()
>> which assumes that interrupts should be ACKed.
>
> You can also just emulate the state transition -- since you know 
> you're dealing with a flat protected-mode or long-mode OS (and just 
> make that a condition of enabling the feature) you don't have to deal 
> with all the strange combinations of directions that an unrestricted 
> x86 event can take.  Since it's an exception, it is unconditional.

Do you mean create the stack frame manually?  I'd really like to avoid 
that for many reasons, one of which is performance (need to do all the 
virt-to-phys walks manually), the other is that we're certain to end up 
with something horribly underspecified.  I'd really like to keep as 
close as possible to the hardware.  For the alternative approach, see Xen.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/