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
58 matches
Mail list logo
