On 09/01/15 08:02, Tian, Kevin wrote:
>> From: Tim Deegan [mailto:t...@xen.org]
>> Sent: Thursday, January 08, 2015 8:43 PM
>>
>> Hi,
>>
Not really. The IOMMU tables are also 64-bit so there must be enough
addresses to map all of RAM. There shouldn't be any need for these
mappings
On Fri, Jan 09, 2015 at 08:02:48AM +, Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > Sent: Thursday, January 08, 2015 8:43 PM
> >
> > Hi,
> >
> > > > Not really. The IOMMU tables are also 64-bit so there must be enough
> > > > addresses to map all of RAM. There shouldn't
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Thursday, January 08, 2015 8:43 PM
>
> Hi,
>
> > > Not really. The IOMMU tables are also 64-bit so there must be enough
> > > addresses to map all of RAM. There shouldn't be any need for these
> > > mappings to be _contiguous_, btw. You just nee
Hi,
At 08:56 + on 06 Jan (1420530995), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote:
> > > but just to confirm one point. from my understanding whether it's a
> > > mapping operation doesn't really matter. We can inv
On Tue, 2015-01-06 at 08:42 +, Tian, Kevin wrote:
> > From: George Dunlap
> > Sent: Monday, January 05, 2015 11:50 PM
> >
> > On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin wrote:
> > >> We're not there in the current design, purely because XenGT has to be
> > >> in dom0 (so it can trivially Do
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Thursday, December 18, 2014 11:47 PM
>
> Hi,
>
> At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote:
> > > I'm afraid not. There's nothing worrying per se in a backend knowing
> > > the MFNs of the pages -- the worry is that the backend can
> From: George Dunlap
> Sent: Monday, January 05, 2015 11:50 PM
>
> On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin wrote:
> >> We're not there in the current design, purely because XenGT has to be
> >> in dom0 (so it can trivially DoS Xen by rebooting the host).
> >
> > Can we really decouple dom0
On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin wrote:
>> We're not there in the current design, purely because XenGT has to be
>> in dom0 (so it can trivially DoS Xen by rebooting the host).
>
> Can we really decouple dom0 from DoS Xen? I know there's on-going effort
> like PVH Dom0, however there a
On 18/12/14 16:08, Tim Deegan wrote:
>> yep. Just curious, I thought stubdomain is not popularly used. typical
>> > case is to have qemu in dom0. is this still true? :-)
> Some do and some don't. :) High-security distros like Qubes and
> XenClient do. You can enable it in xl config files pretty e
Hi,
At 06:29 + on 12 Dec (1418362182), Tian, Kevin wrote:
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.
Ah, but it does -- it's putting thousands of lines of code int
Hi,
At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote:
> > I'm afraid not. There's nothing worrying per se in a backend knowing
> > the MFNs of the pages -- the worry is that the backend can pass the
> > MFNs to hardware. If the check happens only at lookup time, then XenGT
> > can (eith
>>> On 15.12.14 at 17:15, wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 16:22, wrote:
>> > On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >> >>> On 15.12.14 at 10:05, wrote:
>> >> > yes, definitely host RAM is the upper limit, and what I'm concerning
>> >> > here
>> >> > is
On 15/12/14 16:15, Stefano Stabellini wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
> On 15.12.14 at 16:22, wrote:
>>> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>> On 15.12.14 at 10:05, wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how t
On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 16:22, wrote:
> > On Mon, 15 Dec 2014, Jan Beulich wrote:
> >> >>> On 15.12.14 at 10:05, wrote:
> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> >> > is how to reserve (at boot time) or allocate (on-dem
>>> On 15.12.14 at 16:22, wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 10:05, wrote:
>> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> > resource, w/o collision w
On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 10:05, wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (balloon
>>> On 15.12.14 at 12:16, wrote:
> I expect to have everything mapped into the available mapping space,
> and is asking for suggestions what's the best way to find and reserve
> available PFNs in a way not conflicting with other usages (either
> virtualization features like ballooning that you men
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 15, 2014 5:23 PM
>
> >>> On 15.12.14 at 10:05, wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o
>>> On 15.12.14 at 10:05, wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how to reserve (at boot time) or allocate (on-demand) such large PFN
> resource, w/o collision with other PFN reservation usage (ballooning
> should be fine since it's operating existi
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 15, 2014 4:45 PM
>
> >>> On 15.12.14 at 07:25, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >>> On 12.12.14 at 08:24, wrote:
> >> > - how is BFN or unused address (what do you mean by address here?)
> >> >
>>> On 15.12.14 at 07:25, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >>> On 12.12.14 at 08:24, wrote:
>> > - how is BFN or unused address (what do you mean by address here?)
>> > allocated? does it need present in guest physical memory at boot time,
>> > or just finding some holes
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 12, 2014 6:54 PM
>
> >>> On 12.12.14 at 08:24, wrote:
> > - is there existing _map_ call for this purpose per your knowledge, or
> > a new one is required? If the latter, what's the additional logic to be
> > implemented ther
>>> On 12.12.14 at 08:24, wrote:
> - is there existing _map_ call for this purpose per your knowledge, or
> a new one is required? If the latter, what's the additional logic to be
> implemented there?
I think the answer to this depends on whether you want to use
grants. The goal of using the nati
> From: Tian, Kevin
> Sent: Friday, December 12, 2014 2:30 PM
> >
> > Conclusion
> > --
> >
> > That's enough rambling from me -- time to come back down to earth.
> > While I think it's useful to think about all these things, we don't
> > want to get carried away. :) And as I said, for som
> From: Tim Deegan
> Sent: Friday, December 12, 2014 12:47 AM
>
> Hi,
>
> At 01:41 + on 11 Dec (1418258504), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:t...@xen.org]
> > > It is Xen's job to isolate VMs from each other. As part of that, Xen
> > > uses the MMU, nested paging, and IOMMU
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Friday, December 12, 2014 5:29 AM
>
> Hi, again. :)
>
> As promised, I'm going to talk about more abstract design
> considerations. Thi will be a lot less concrete than in the other
> email, and about a larger range of things. Some of of them may
Hi, again. :)
As promised, I'm going to talk about more abstract design
considerations. Thi will be a lot less concrete than in the other
email, and about a larger range of things. Some of of them may not be
really desirable - or even possible.
[ TL;DR: read the other reply with the practical s
Hi,
At 01:41 + on 11 Dec (1418258504), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > It is Xen's job to isolate VMs from each other. As part of that, Xen
> > uses the MMU, nested paging, and IOMMUs to control access to RAM. Any
> > software component that can pass a raw
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, December 10, 2014 6:11 PM
>
> On Wed, 2014-12-10 at 01:48 +, Tian, Kevin wrote:
> > I'm not familiar with Arm architecture, but based on a brief reading it's
> > for the assigned case where the MMU is exclusive owned by a
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 10, 2014 6:36 PM
>
> >>> On 10.12.14 at 02:14, wrote:
> >> From: Tim Deegan [mailto:t...@xen.org]
> >> It's been suggested before that we should revive this hypercall, and I
> >> don't think it's a good idea. Whenever a
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Wednesday, December 10, 2014 6:55 PM
>
> At 01:14 + on 10 Dec (1418170461), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:t...@xen.org]
> > > Sent: Tuesday, December 09, 2014 6:47 PM
> > >
> > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zha
On 10/12/14 09:51, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>>
> On 10.12.14 at 09:47, wrote:
>>> two translation paths in assigned case:
>>>
>>> 1. [direct CPU access from VM], with partitioned PCI aperture
>>> resource,
At 01:14 + on 10 Dec (1418170461), Tian, Kevin wrote:
> > From: Tim Deegan [mailto:t...@xen.org]
> > Sent: Tuesday, December 09, 2014 6:47 PM
> >
> > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > > Hi all,
> > >
> > >As you can see, we are pushing our XenGT patches to the ups
>>> On 10.12.14 at 02:14, wrote:
>> From: Tim Deegan [mailto:t...@xen.org]
>> It's been suggested before that we should revive this hypercall, and I
>> don't think it's a good idea. Whenever a domain needs to know the
>> actual MFN of another domain's memory it's usually because the
>> security
On Wed, 2014-12-10 at 01:48 +, Tian, Kevin wrote:
> I'm not familiar with Arm architecture, but based on a brief reading it's
> for the assigned case where the MMU is exclusive owned by a VM, so
> some type of MMU virtualization is required and it's straightforward.
> However XenGT is a shared
>>> On 10.12.14 at 10:51, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, December 10, 2014 5:17 PM
>>
>> >>> On 10.12.14 at 09:47, wrote:
>> > two translation paths in assigned case:
>> >
>> > 1. [direct CPU access from VM], with partitioned PCI aperture
>> > resourc
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 10, 2014 5:17 PM
>
> >>> On 10.12.14 at 09:47, wrote:
> > two translation paths in assigned case:
> >
> > 1. [direct CPU access from VM], with partitioned PCI aperture
> > resource, every VM can access a portion of PCI ape
>>> On 10.12.14 at 09:47, wrote:
> two translation paths in assigned case:
>
> 1. [direct CPU access from VM], with partitioned PCI aperture
> resource, every VM can access a portion of PCI aperture directly.
>
> - CPU page table/EPT: CPU virtual address->PCI aperture
> - PCI aperture - bar base
> From: Tian, Kevin
> Sent: Wednesday, December 10, 2014 4:48 PM
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, December 10, 2014 4:39 PM
> >
> > >>> On 10.12.14 at 02:07, wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Tuesday, December 09, 2014
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 10, 2014 4:39 PM
>
> >>> On 10.12.14 at 02:07, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, December 09, 2014 6:50 PM
> >>
> >> >>> On 09.12.14 at 11:37, wrote:
> >> > On 12/9/2014 6:19 PM
>>> On 10.12.14 at 02:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, December 09, 2014 6:50 PM
>>
>> >>> On 09.12.14 at 11:37, wrote:
>> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> >> I think use of an raw mfn value currently works only because dom0 is using
>>
r (Xen.org); jbeul...@suse.com;
> > Xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
> > to
> > mfn.
> >
> > On Tue, 2014-12-09 at 11:17 +, Paul Durrant wrote:
> > > > -Original Messag
> From: Malcolm Crossley
> Sent: Tuesday, December 09, 2014 6:52 PM
>
> On 09/12/14 10:37, Yu, Zhang wrote:
> >
> >
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is
> >> using a 1:1 IOMMU mapping scheme. Is my understanding cor
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Tuesday, December 09, 2014 6:47 PM
>
> At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> > Hi all,
> >
> >As you can see, we are pushing our XenGT patches to the upstream. One
> > feature we need in xen is to translate guests' gfn to mfn
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 09, 2014 6:50 PM
>
> >>> On 09.12.14 at 11:37, wrote:
> > On 12/9/2014 6:19 PM, Paul Durrant wrote:
> >> I think use of an raw mfn value currently works only because dom0 is using
> a
> > 1:1 IOMMU mapping scheme. Is my unde
> -Original Message-
> From: Ian Campbell
> Sent: 09 December 2014 11:29
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); jbeul...@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to t
@lists.xen.org
> > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn
> > to
> > mfn.
> >
> > On Tue, 2014-12-09 at 11:05 +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Tim Deegan [mailto:t...@xe
On 09/12/14 11:23, Jan Beulich wrote:
On 09.12.14 at 12:17, wrote:
>> I think we want be able to avoid setting up a PTE in the MMU since it's not
>> needed in most (or perhaps all?) cases.
>
> With shared page tables, there's no way to do one without the other.
>
Interestingly the IOMMU in
>>> On 09.12.14 at 12:17, wrote:
> I think we want be able to avoid setting up a PTE in the MMU since it's not
> needed in most (or perhaps all?) cases.
With shared page tables, there's no way to do one without the other.
Jan
___
Xen-devel mailing l
> -Original Message-
> From: Ian Campbell
> Sent: 09 December 2014 11:11
> To: Paul Durrant
> Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); jbeul...@suse.com;
> Xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] One question about the hypercall to t
On Tue, 2014-12-09 at 11:05 +, Paul Durrant wrote:
> > -Original Message-
> > From: Tim Deegan [mailto:t...@xen.org]
> > Sent: 09 December 2014 10:47
> > To: Yu, Zhang
> > Cc: Paul Durrant; Keir (Xen.org); jbeul...@suse.com; Kevin Tian; Xen-
> > de...@lists.xen.org
> > Subject: Re: One
> -Original Message-
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: 09 December 2014 10:47
> To: Yu, Zhang
> Cc: Paul Durrant; Keir (Xen.org); jbeul...@suse.com; Kevin Tian; Xen-
> de...@lists.xen.org
> Subject: Re: One question about the hypercall to translate gfn to mfn.
>
> At 18:10 +
On 09/12/14 10:37, Yu, Zhang wrote:
>
>
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is
>> using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
>> you really need raw mfn values?
> Thanks for your quick response,
>>> On 09.12.14 at 11:37, wrote:
> On 12/9/2014 6:19 PM, Paul Durrant wrote:
>> I think use of an raw mfn value currently works only because dom0 is using a
> 1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need
> raw mfn values?
> Thanks for your quick response, Paul.
>
At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
> Hi all,
>
>As you can see, we are pushing our XenGT patches to the upstream. One
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> device model.
>
>Here we may have 2 similar solutions:
>1> Paul told
On 12/9/2014 6:19 PM, Paul Durrant wrote:
I think use of an raw mfn value currently works only because dom0 is using a
1:1 IOMMU mapping scheme. Is my understanding correct, or do you really need
raw mfn values?
Thanks for your quick response, Paul.
Well, not exactly for this case. :)
In Xen
>>> On 09.12.14 at 11:10, wrote:
>As you can see, we are pushing our XenGT patches to the upstream. One
> feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
> device model.
>
>Here we may have 2 similar solutions:
>1> Paul told me(and thank you, Paul :)) that th
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 09 December 2014 10:11
> To: Paul Durrant; Keir (Xen.org); Tim (Xen.org); jbeul...@suse.com; Kevin
> Tian; Xen-devel@lists.xen.org
> Subject: One question about the hypercall to translate gfn to mfn.
>
> Hi
Hi all,
As you can see, we are pushing our XenGT patches to the upstream. One
feature we need in xen is to translate guests' gfn to mfn in XenGT dom0
device model.
Here we may have 2 similar solutions:
1> Paul told me(and thank you, Paul :)) that there used to be a
hypercall, XENMEM_tr
59 matches
Mail list logo
