[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A032FDD.8020209@redhat.com>
Date: Thu, 07 May 2009 22:00:45 +0300
From: Avi Kivity <avi@...hat.com>
To: Gregory Haskins <ghaskins@...ell.com>
CC: Gregory Haskins <gregory.haskins@...il.com>,
Chris Wright <chrisw@...s-sol.org>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Anthony Liguori <anthony@...emonkey.ws>
Subject: Re: [RFC PATCH 0/3] generic hypercall support
Gregory Haskins wrote:
> Avi Kivity wrote:
>
>> Gregory Haskins wrote:
>>
>>> I guess technically mmio can just be a simple access of the page which
>>> would be problematic to trap locally without a PF. However it seems
>>> that most mmio always passes through a ioread()/iowrite() call so this
>>> is perhaps the hook point. If we set the stake in the ground that mmios
>>> that go through some other mechanism like PFs can just hit the "slow
>>> path" are an acceptable casualty, I think we can make that work.
>>>
>>>
>> That's my thinking exactly.
>>
>
> Cool, I will code this up and submit it. While Im at it, Ill run it
> through the "nullio" ringer, too. ;) It would be cool to see the
> pv-mmio hit that 2.07us number. I can't think of any reason why this
> will not be the case.
>
Don't - it's broken. It will also catch device assignment mmio and
hypercall them.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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/
Powered by blists - more mailing lists