From xen-devel-bounces@lists.xen.org Wed May 21 09:46:43 2014
Received: (at maildrop) by bugs.xenproject.org; 21 May 2014 08:46:43 +0000
Received: from lists.xen.org ([50.57.142.19])
by bugs.xenproject.org with esmtp (Exim 4.80)
(envelope-from )
id 1Wn2Ad-0006pc-PW
for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 21 May 2014 09:46:43 +0100
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from )
id 1Wn241-0007gi-NK; Wed, 21 May 2014 08:39:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
by lists.xen.org with esmtp (Exim 4.72)
(envelope-from ) id 1Wn240-0007fi-By
for xen-devel@lists.xen.org; Wed, 21 May 2014 08:39:52 +0000
Received: from [85.158.139.211:31539] by server-17.bemta-5.messagelabs.com id
38/84-09046-7566C735; Wed, 21 May 2014 08:39:51 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1400661589!5508704!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzkwOTcx\n
X-StarScan-Received:
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 593 invoked from network); 21 May 2014 08:39:50 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
by server-7.tower-206.messagelabs.com with SMTP;
21 May 2014 08:39:50 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
by orsmga102.jf.intel.com with ESMTP; 21 May 2014 01:34:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.98,878,1392192000"; d="scan'208";a="515309143"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
by orsmga001.jf.intel.com with ESMTP; 21 May 2014 01:39:25 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by
FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
(TLS) id 14.3.123.3; Wed, 21 May 2014 01:37:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server
(TLS) id 14.3.123.3; Wed, 21 May 2014 01:37:39 -0700
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.192]) by
SHSMSX151.ccr.corp.intel.com ([169.254.3.7]) with mapi id
14.03.0123.003; Wed, 21 May 2014 16:37:35 +0800
From: "Zhang, Yang Z"
To: Jan Beulich
Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log
dirty to track vram
Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZtIw0CAgAFyMyCAAIpWgIAAhr6Q
Date: Wed, 21 May 2014 08:37:35 +0000
Message-ID:
References: <20140210080314.GA758@deinos.phlegethon.org>
<20140211090202.GC92054@deinos.phlegethon.org>
<20140211115553.GB97288@deinos.phlegethon.org>
<52FA2C63020000780011B201@nat28.tlf.novell.com>
<52FA480D.9040707@eu.citrix.com>
<52FCE8BE.8050105@eu.citrix.com>
<52FCF90F020000780011C29A@nat28.tlf.novell.com>
<20140213162022.GE82703@deinos.phlegethon.org>
<537B1E520200007800013EB7@mail.emea.novell.com>
<537B4EA70200007800014085@mail.emea.novell.com>
<537C769B02000078000145C2@mail.emea.novell.com>
In-Reply-To: <537C769B02000078000145C2@mail.emea.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: George Dunlap ,
"andrew.cooper3@citrix.com" ,
Tim Deegan ,
"xen-devel@lists.xen.org" ,
"KeirFraser\(keir.xen@gmail.com\)" ,
"Nakajima, Jun" , "Zhang,
Xiantao"
Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log
dirty to track vram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
Jan Beulich wrote on 2014-05-21:
>>>> On 21.05.14 at 03:02, wrote:
>> Jan Beulich wrote on 2014-05-20:
>>>>>> On 20.05.14 at 12:12, wrote:
>>>> On Tue, May 20, 2014 at 8:20 AM, Jan Beulich
> wrote:
>>>>>>>> On 20.05.14 at 05:13, wrote:
>>>>>> George Dunlap wrote on 2014-05-19:
>>>>>>> Avoiding these by "hoping" that the guest OS doesn't DMA into a
>>>>>>> video buffer isn't really robust enough. I think that was Tim
>>>>>>> and Jan's
>>>>>>
>>>>>> Video buffer is only one case. How we can prevent the DMA to other
>>>>>> reserved region?
>>>>>
>>>>> You continue to neglect the difference: Accessing VRAM this way is
>>>>> legitimate (and potentially useful). And - as just said in the
>>>>> other reply - ideally we'd also simply ignore accesses to reserved
>>
>> Can you give an example of what legitmate case you are mentioned twice(You
>> mentioned it also in other reply)?
>
> What's wrong with loading some graphics data right from an I/O device
> (disk, network) into the frame buffer?
Yes, it is ok. But we are talking about the DMA access to a 'readonly' buffer. It is totally a wrong usage model to me.
>
>> I cannot understand why we need to
>> restrict the CPU access to VRAM region but allow accessing from device.
>
> We'd love to also do this for device accesses, but to date IOMMU
> fault are unrecoverable, and hence this is not an option.
>
>> As I known, for gfx passthrough, both device and CPU are able to access
>> them. And for emulated gfx, only software will access it which same as
>> current we see in Xen.
>
> Why's that? I.e. why should a guest with emulated graphics not be
> able to program a passed through device to access the VRAM directly?
I think you confused the background of the issue: the essence of the issue is that we marked all pages as read-only and meanwhile we allow DMA to access those page. So the right solution is only mark the required page (in this case means VRAM region) as readonly and if guest still DMA to that region, then any unpredictable behavior to that guest is reasonable. What you said before totally ignore the 'read-only' thing. If there is no read-only operation, there will be no problem and no discussion around it.
>
>>>>> regions (and in fact we try to, by not immediately bringing down a
>>>>> guest device doing such).
>>>>
>>>> On the other hand, just to play devil's advocate here: Implementing
>>>> separate IOMMU tables (including superpages) isn't free; it has a
>>>> non-negligible cost, both in initial developer time, continuing
>>>> maintenance (code complexity, fixing bugs), extra memory at
>>>> run-time, &c.
>>>>
>>>> Of all the things we could invest that developer time doing, why
>>>> should we make it possible to DMA into VRAM, rather than doing
>>>> something else?
>>>
>>> While I agree that the question is valid, my position really is that
>>> it was a mistake to implement the IOMMU code without superpage
>>
>> We support the superpage via sharing EPT and VT-d pagetable.
>
> I.e. without EPT no superpages. Afaict there's no such limitation on
> the AMD side.
I don't think this is a 'limitation'. The original motivation to sharing page table is to use memory efficiently and easy for code maintain. And when we tried to add superpage support, we follow this way (we only need to change one copy of page table). But you think it is a limitation. I cannot understand.
>
>>> support, i.e. I view this as a shortcoming independent of the VRAM
>>> issue, and I would want to see this fixed rather sooner than later.
>>> Had it been done properly from the beginning (like one would expect
>>> for non-experimental code), a lot of this discussion could have been
>>> avoided, and we wouldn't have had to take the respective workaround
>>> close to the 4.4 release.
>>
>> I still think the best solution is fixing the VRAM global log dirty
>> mechanism which my previous patch already did. Because I cannot see any
>> benefit with separating the page table.
>
> You didn't in any way negate the condition of superpage support to be
> added post-4.4 in order for your other change to go in: Neither
> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01230.html
> nor
> http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01236.html
> have been responded to by you. By not doing so, to me at least you
> implicitly accepted the condition. And by now refusing to meet it, you
> basically tell us that we shouldn't be doing compromises like this with
> you in the future.
I have said before I am totally unware of it. And I know it only two days ago after someone told me. So please do not confuse this with the thing what we are discussing now. If you think I gave a promise implicitly at that time, I am sorry to let you think so.
As I said in previous thread, if we can prove that add hugepage for the separate VT-d page table is the only choice to solve problem, then now I am promising that I will do it ASAP. But till now, I didn't see any point that we must to have it. To me, it is still a nice to have feature.
>
> Jan
Best regards,
Yang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel