On Wed, Oct 17, 2012 at 04:51:17PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >In the past it used to point to 'sidt' (native_store_idt) operation
> >which is a non-privileged operation. This resulted in the
> >'struct desc_ptr' value containing the addres
On 10/18/2012 07:45 AM, Konrad Rzeszutek Wilk wrote:
OK... this seems like another excellent set of pvops calls that
should be nukable to Kingdom Come. There is no reason, ever, to
read the IDT and GDT from the kernel... the kernel already knows
what they should be!
Even during suspend and re
On Wed, Oct 17, 2012 at 04:51:17PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >In the past it used to point to 'sidt' (native_store_idt) operation
> >which is a non-privileged operation. This resulted in the
> >'struct desc_ptr' value containing the addres
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
In the past it used to point to 'sidt' (native_store_idt) operation
which is a non-privileged operation. This resulted in the
'struct desc_ptr' value containing the address of Xen's IDT table,
instead of the IDT table that Linux thinks its usin
4 matches
Mail list logo
