>>> On 22.04.16 at 14:54, wrote:
> On 04/22/16 06:36, Jan Beulich wrote:
>> >>> On 22.04.16 at 14:26, wrote:
>> > On 04/22/16 04:53, Jan Beulich wrote:
>> >> Perhaps I have got confused by the back and forth. If we're to
>> >> use struct page_info, then everything should be following a
>> >> simi
On 04/22/16 06:36, Jan Beulich wrote:
> >>> On 22.04.16 at 14:26, wrote:
> > On 04/22/16 04:53, Jan Beulich wrote:
> >> Perhaps I have got confused by the back and forth. If we're to
> >> use struct page_info, then everything should be following a
> >> similar flow to what happens for normal RAM,
>>> On 22.04.16 at 14:26, wrote:
> On 04/22/16 04:53, Jan Beulich wrote:
>> Perhaps I have got confused by the back and forth. If we're to
>> use struct page_info, then everything should be following a
>> similar flow to what happens for normal RAM, i.e. normal page
>> allocation, and normal assig
On 04/22/16 04:53, Jan Beulich wrote:
> >>> On 22.04.16 at 12:16, wrote:
> > On 04/22/16 02:24, Jan Beulich wrote:
> > [..]
> >> >> >> Well, using existing range struct to manage guest access permissions
> >> >> >> to nvdimm could consume too much space which could not fit in either
> >> >> >> mem
>>> On 22.04.16 at 12:16, wrote:
> On 04/22/16 02:24, Jan Beulich wrote:
> [..]
>> >> >> Well, using existing range struct to manage guest access permissions
>> >> >> to nvdimm could consume too much space which could not fit in either
>> >> >> memory or nvdimm. If the above solution looks really
On 04/22/16 02:24, Jan Beulich wrote:
[..]
> >> >> Well, using existing range struct to manage guest access permissions
> >> >> to nvdimm could consume too much space which could not fit in either
> >> >> memory or nvdimm. If the above solution looks really error-prone,
> >> >> perhaps we can still
>>> On 22.04.16 at 04:36, wrote:
> On 04/21/16 01:04, Jan Beulich wrote:
>> >>> On 21.04.16 at 07:09, wrote:
>> > On 04/12/16 16:45, Haozhong Zhang wrote:
>> >> On 04/08/16 09:52, Jan Beulich wrote:
>> >> > >>> On 08.04.16 at 07:02, wrote:
>> >> > > On 03/29/16 04:49, Jan Beulich wrote:
>> >> >
On 04/21/16 01:04, Jan Beulich wrote:
> >>> On 21.04.16 at 07:09, wrote:
> > On 04/12/16 16:45, Haozhong Zhang wrote:
> >> On 04/08/16 09:52, Jan Beulich wrote:
> >> > >>> On 08.04.16 at 07:02, wrote:
> >> > > On 03/29/16 04:49, Jan Beulich wrote:
> >> > >> >>> On 29.03.16 at 12:10, wrote:
> >>
>>> On 21.04.16 at 07:09, wrote:
> On 04/12/16 16:45, Haozhong Zhang wrote:
>> On 04/08/16 09:52, Jan Beulich wrote:
>> > >>> On 08.04.16 at 07:02, wrote:
>> > > On 03/29/16 04:49, Jan Beulich wrote:
>> > >> >>> On 29.03.16 at 12:10, wrote:
>> > >> > On 03/29/16 03:11, Jan Beulich wrote:
>> > >>
On 04/12/16 16:45, Haozhong Zhang wrote:
> On 04/08/16 09:52, Jan Beulich wrote:
> > >>> On 08.04.16 at 07:02, wrote:
> > > On 03/29/16 04:49, Jan Beulich wrote:
> > >> >>> On 29.03.16 at 12:10, wrote:
> > >> > On 03/29/16 03:11, Jan Beulich wrote:
> > >> >> >>> On 29.03.16 at 10:47, wrote:
> >
On 04/08/16 09:52, Jan Beulich wrote:
> >>> On 08.04.16 at 07:02, wrote:
> > On 03/29/16 04:49, Jan Beulich wrote:
> >> >>> On 29.03.16 at 12:10, wrote:
> >> > On 03/29/16 03:11, Jan Beulich wrote:
> >> >> >>> On 29.03.16 at 10:47, wrote:
> > [..]
> >> >> > I still cannot find a neat approach to
>>> On 08.04.16 at 07:02, wrote:
> On 03/29/16 04:49, Jan Beulich wrote:
>> >>> On 29.03.16 at 12:10, wrote:
>> > On 03/29/16 03:11, Jan Beulich wrote:
>> >> >>> On 29.03.16 at 10:47, wrote:
> [..]
>> >> > I still cannot find a neat approach to manage guest permissions for
>> >> > nvdimm pages.
On 03/29/16 04:49, Jan Beulich wrote:
> >>> On 29.03.16 at 12:10, wrote:
> > On 03/29/16 03:11, Jan Beulich wrote:
> >> >>> On 29.03.16 at 10:47, wrote:
[..]
> >> > I still cannot find a neat approach to manage guest permissions for
> >> > nvdimm pages. A possible one is to use a per-domain bitma
>>> On 29.03.16 at 12:10, wrote:
> On 03/29/16 03:11, Jan Beulich wrote:
>> >>> On 29.03.16 at 10:47, wrote:
>> > On 03/17/16 22:21, Haozhong Zhang wrote:
>> >> On 03/17/16 14:00, Ian Jackson wrote:
>> >> > Haozhong Zhang writes (&
On 03/29/16 03:11, Jan Beulich wrote:
> >>> On 29.03.16 at 10:47, wrote:
> > On 03/17/16 22:21, Haozhong Zhang wrote:
> >> On 03/17/16 14:00, Ian Jackson wrote:
> >> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM
> >>
>>> On 29.03.16 at 10:47, wrote:
> On 03/17/16 22:21, Haozhong Zhang wrote:
>> On 03/17/16 14:00, Ian Jackson wrote:
>> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM
>> > support for Xen"):
>> > > QEMU
On 03/17/16 22:21, Haozhong Zhang wrote:
> On 03/17/16 14:00, Ian Jackson wrote:
> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM
> > support for Xen"):
> > > QEMU keeps mappings of guest memory because (1) that mapping is
> > > c
Hi Jan and Konrad,
On 03/04/16 15:30, Haozhong Zhang wrote:
> Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
> or files on NVDIMM. We can move that work to toolstack and pass SPA
> ranges got by toolstack to qemu. In this way, no privileged operations
> (mmap/mlock/...) are
Jan Beulich writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for
Xen"):
> So that again leaves unaddressed the question of what you
> imply to do when a guest elects to use such a page as page
> table. I'm afraid any attempt of yours to invent something that
&
>>> On 17.03.16 at 09:58, wrote:
> On 03/16/16 09:23, Jan Beulich wrote:
>> >>> On 16.03.16 at 15:55, wrote:
>> > On 03/16/16 08:23, Jan Beulich wrote:
>> >> >>> On 16.03.16 at 14:55, wrote:
>> >> > On 03/16/16 07:16, Jan Beulich wrote:
>> >> >> And
>> >> >> talking of fragmentation - how do you
> Then there is another problem (which also exists in the current
> design): does Xen need to emulate NVDIMM _DSM for dom0? Take the _DSM
> that access label storage area (for namespace) for example:
No. And it really can't as each vendors _DSM is different - and there
is no ACPI AML interpreter i
>>> On 17.03.16 at 13:44, wrote:
> On 03/17/16 05:04, Jan Beulich wrote:
>> >>> On 17.03.16 at 09:58, wrote:
>> > On 03/16/16 09:23, Jan Beulich wrote:
>> >> >>> On 16.03.16 at 15:55, wrote:
>> >> > On 03/16/16 08:23, Jan Beulich wrote:
>> >> >> >>> On 16.03.16 at 14:55, wrote:
>> >> >> > On 03
On 03/17/16 14:00, Ian Jackson wrote:
> Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
> for Xen"):
> > QEMU keeps mappings of guest memory because (1) that mapping is
> > created by itself, and/or (2) certain device emulation needs to
On 03/17/16 22:12, Xu, Quan wrote:
> On March 17, 2016 9:37pm, Haozhong Zhang wrote:
> > For PV guests (if we add vNVDIMM support for them in future), as I'm going
> > to
> > use page_info struct for it, I suppose the current mechanism in Xen can
> > handle
> > this case. I'm not familiar with P
On 03/16/16 08:23, Jan Beulich wrote:
> >>> On 16.03.16 at 14:55, wrote:
> > On 03/16/16 07:16, Jan Beulich wrote:
> >> Which reminds me: When considering a file on NVDIMM, how
> >> are you making sure the mapping of the file to disk (i.e.
> >> memory) blocks doesn't change while the guest has acc
On Wed, Mar 16, 2016 at 08:55:08PM +0800, Haozhong Zhang wrote:
> Hi Jan and Konrad,
>
> On 03/04/16 15:30, Haozhong Zhang wrote:
> > Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
> > or files on NVDIMM. We can move that work to toolstack and pass SPA
> > ranges got by too
>>> On 17.03.16 at 14:29, wrote:
> On 03/17/16 06:59, Jan Beulich wrote:
>> >>> On 17.03.16 at 13:44, wrote:
>> > Hmm, making Xen has full control could at least make reserving space
>> > on NVDIMM easier. I guess full control does not include manipulating
>> > file systems on NVDIMM which can be
On 03/16/16 07:16, Jan Beulich wrote:
> >>> On 16.03.16 at 13:55, wrote:
> > Hi Jan and Konrad,
> >
> > On 03/04/16 15:30, Haozhong Zhang wrote:
> >> Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
> >> or files on NVDIMM. We can move that work to toolstack and pass SPA
> >
>>> On 16.03.16 at 13:55, wrote:
> Hi Jan and Konrad,
>
> On 03/04/16 15:30, Haozhong Zhang wrote:
>> Suddenly realize it's unnecessary to let QEMU get SPA ranges of NVDIMM
>> or files on NVDIMM. We can move that work to toolstack and pass SPA
>> ranges got by toolstack to qemu. In this way, no p
On 03/16/16 09:23, Jan Beulich wrote:
> >>> On 16.03.16 at 15:55, wrote:
> > On 03/16/16 08:23, Jan Beulich wrote:
> >> >>> On 16.03.16 at 14:55, wrote:
> >> > On 03/16/16 07:16, Jan Beulich wrote:
> >> >> Which reminds me: When considering a file on NVDIMM, how
> >> >> are you making sure the ma
On 03/17/16 06:59, Jan Beulich wrote:
> >>> On 17.03.16 at 13:44, wrote:
> > On 03/17/16 05:04, Jan Beulich wrote:
> >> >>> On 17.03.16 at 09:58, wrote:
> >> > On 03/16/16 09:23, Jan Beulich wrote:
> >> >> >>> On 16.03.16 at 15:55, wrote:
> >> >> > On 03/16/16 08:23, Jan Beulich wrote:
> >> >> >
On 03/17/16 11:05, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for
> Xen"):
> > So that again leaves unaddressed the question of what you
> > imply to do when a guest elects to use such a page as page
> > table.
>>> On 16.03.16 at 14:55, wrote:
> On 03/16/16 07:16, Jan Beulich wrote:
>> Which reminds me: When considering a file on NVDIMM, how
>> are you making sure the mapping of the file to disk (i.e.
>> memory) blocks doesn't change while the guest has access
>> to it, e.g. due to some defragmentation g
On March 17, 2016 9:37pm, Haozhong Zhang wrote:
> For PV guests (if we add vNVDIMM support for them in future), as I'm going to
> use page_info struct for it, I suppose the current mechanism in Xen can handle
> this case. I'm not familiar with PV memory management
The below web may be helpful:
h
>>> On 16.03.16 at 15:55, wrote:
> On 03/16/16 08:23, Jan Beulich wrote:
>> >>> On 16.03.16 at 14:55, wrote:
>> > On 03/16/16 07:16, Jan Beulich wrote:
>> >> Which reminds me: When considering a file on NVDIMM, how
>> >> are you making sure the mapping of the file to disk (i.e.
>> >> memory) bloc
>>> On 17.03.16 at 14:37, wrote:
> On 03/17/16 11:05, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
>> for
> Xen"):
>> > So that again leaves unaddressed the question of what you
>> > imp
On 03/17/16 07:56, Jan Beulich wrote:
> >>> On 17.03.16 at 14:37, wrote:
> > On 03/17/16 11:05, Ian Jackson wrote:
> >> Jan Beulich writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
> >> for
> > Xen"):
> >> > So that a
On 03/17/16 05:04, Jan Beulich wrote:
> >>> On 17.03.16 at 09:58, wrote:
> > On 03/16/16 09:23, Jan Beulich wrote:
> >> >>> On 16.03.16 at 15:55, wrote:
> >> > On 03/16/16 08:23, Jan Beulich wrote:
> >> >> >>> On 16.03.16 at 14:55, wrote:
> >> >> > On 03/16/16 07:16, Jan Beulich wrote:
> >> >> >
Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
for Xen"):
> QEMU keeps mappings of guest memory because (1) that mapping is
> created by itself, and/or (2) certain device emulation needs to access
> the guest memory. But for vNVDIMM, I'm going
On 03/09/16 09:17, Jan Beulich wrote:
> >>> On 09.03.16 at 13:22, wrote:
> > On 03/08/16 02:27, Jan Beulich wrote:
> >> >>> On 08.03.16 at 10:15, wrote:
[...]
> > I should reexplain the choice of data structures and where to put them.
> >
> > For handling MCE for NVDIMM, we need to track followi
>>> On 09.03.16 at 13:22, wrote:
> On 03/08/16 02:27, Jan Beulich wrote:
>> >>> On 08.03.16 at 10:15, wrote:
>> > More thoughts on reserving NVDIMM space for per-page structures
>> >
>> > Currently, a per-page struct for managing mapping of NVDIMM pages may
>> > include following fields:
>> >
>
On 03/08/16 02:27, Jan Beulich wrote:
> >>> On 08.03.16 at 10:15, wrote:
> > More thoughts on reserving NVDIMM space for per-page structures
> >
> > Currently, a per-page struct for managing mapping of NVDIMM pages may
> > include following fields:
> >
> > struct nvdimm_page
> > {
> > uint64
>>> On 08.03.16 at 10:15, wrote:
> More thoughts on reserving NVDIMM space for per-page structures
>
> Currently, a per-page struct for managing mapping of NVDIMM pages may
> include following fields:
>
> struct nvdimm_page
> {
> uint64_t mfn;/* MFN of SPA of this NVDIMM page */
>
On 03/04/16 10:20, Haozhong Zhang wrote:
> On 03/02/16 06:03, Jan Beulich wrote:
> > >>> On 02.03.16 at 08:14, wrote:
> > > It means NVDIMM is very possibly mapped in page granularity, and
> > > hypervisor needs per-page data structures like page_info (rather than the
> > > range set style nvdimm_
On 03/07/16 15:53, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 02, 2016 at 03:14:52PM +0800, Haozhong Zhang wrote:
> > On 03/01/16 13:49, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Mar 01, 2016 at 06:33:32PM +, Ian Jackson wrote:
> > > > Haozhong Zhang writes (&q
On Wed, Mar 02, 2016 at 03:14:52PM +0800, Haozhong Zhang wrote:
> On 03/01/16 13:49, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 01, 2016 at 06:33:32PM +, Ian Jackson wrote:
> > > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM
> > > sup
On 02/16/16 05:55, Jan Beulich wrote:
> >>> On 16.02.16 at 12:14, wrote:
> > On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
> >> On 02/04/16 20:24, Stefano Stabellini wrote:
> >> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> >> > > On 02/03/16 15:22, Stefano Stabellini wrote:
> >> > > > On Wed, 3 Feb
On 03/02/16 06:03, Jan Beulich wrote:
> >>> On 02.03.16 at 08:14, wrote:
> > It means NVDIMM is very possibly mapped in page granularity, and
> > hypervisor needs per-page data structures like page_info (rather than the
> > range set style nvdimm_pages) to manage those mappings.
> >
> > Then we w
>>> On 02.03.16 at 08:14, wrote:
> It means NVDIMM is very possibly mapped in page granularity, and
> hypervisor needs per-page data structures like page_info (rather than the
> range set style nvdimm_pages) to manage those mappings.
>
> Then we will face the problem that the potentially huge num
On 03/01/16 13:49, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 01, 2016 at 06:33:32PM +, Ian Jackson wrote:
> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM
> > support for Xen"):
> > > On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
&g
On Tue, Mar 01, 2016 at 06:33:32PM +, Ian Jackson wrote:
> Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
> for Xen"):
> > On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
> > > [someone:]
> > > > (2) For XENM
Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support
for Xen"):
> On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
> > [someone:]
> > > (2) For XENMAPSPACE_gmfn, _gmfn_range and _gmfn_foreign,
> > >(a) never map idx in them to GFNs
>>> On 01.03.16 at 14:51, wrote:
> Haozhong Zhang writes ("Re: [RFC Design Doc] Add vNVDIMM support for Xen"):
>> On 02/29/16 05:04, Jan Beulich wrote:
>> > Which will involve adding how much new code to it?
>>
>> Because hvmloader only accepts AML device rather than arbitrary objects,
>> only co
Haozhong Zhang writes ("Re: [RFC Design Doc] Add vNVDIMM support for Xen"):
> On 02/29/16 05:04, Jan Beulich wrote:
> > Which will involve adding how much new code to it?
>
> Because hvmloader only accepts AML device rather than arbitrary objects,
> only code that builds the outmost part of AML de
On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
> > > > QEMU would always use MFN above guest normal ram and I/O holes for
> > > > vNVDIMM. It would attempt to search in that space for a contiguous range
> > > > that is large enough for that that vNVDIMM devices. Is guest able to
> > > > punch hole
On 02/29/16 05:04, Jan Beulich wrote:
> >>> On 29.02.16 at 12:52, wrote:
> > On 02/29/16 03:12, Jan Beulich wrote:
> >> >>> On 29.02.16 at 10:45, wrote:
> >> > On 02/29/16 02:01, Jan Beulich wrote:
> >> >> >>> On 28.02.16 at 15:48, wrote:
> >> >> > Anyway, we may avoid some conflicts between ACP
>>> On 29.02.16 at 12:52, wrote:
> On 02/29/16 03:12, Jan Beulich wrote:
>> >>> On 29.02.16 at 10:45, wrote:
>> > On 02/29/16 02:01, Jan Beulich wrote:
>> >> >>> On 28.02.16 at 15:48, wrote:
>> >> > Anyway, we may avoid some conflicts between ACPI tables/objects by
>> >> > restricting which tabl
On 02/29/16 03:12, Jan Beulich wrote:
> >>> On 29.02.16 at 10:45, wrote:
> > On 02/29/16 02:01, Jan Beulich wrote:
> >> >>> On 28.02.16 at 15:48, wrote:
> >> > Anyway, we may avoid some conflicts between ACPI tables/objects by
> >> > restricting which tables and objects can be passed from QEMU to
>>> On 29.02.16 at 10:45, wrote:
> On 02/29/16 02:01, Jan Beulich wrote:
>> >>> On 28.02.16 at 15:48, wrote:
>> > Anyway, we may avoid some conflicts between ACPI tables/objects by
>> > restricting which tables and objects can be passed from QEMU to Xen:
>> > (1) For ACPI tables, xen does not acc
On 02/29/16 02:01, Jan Beulich wrote:
> >>> On 28.02.16 at 15:48, wrote:
> > On 02/24/16 09:54, Jan Beulich wrote:
> >> >>> On 24.02.16 at 16:48, wrote:
> >> > On 02/24/16 07:24, Jan Beulich wrote:
> >> >> >>> On 24.02.16 at 14:28, wrote:
> >> >> > On 02/18/16 10:17, Jan Beulich wrote:
> >> >> >
>>> On 28.02.16 at 15:48, wrote:
> On 02/24/16 09:54, Jan Beulich wrote:
>> >>> On 24.02.16 at 16:48, wrote:
>> > On 02/24/16 07:24, Jan Beulich wrote:
>> >> >>> On 24.02.16 at 14:28, wrote:
>> >> > On 02/18/16 10:17, Jan Beulich wrote:
>> >> >> >>> On 01.02.16 at 06:44, wrote:
>> >> >> > 3.3 G
On 02/24/16 09:54, Jan Beulich wrote:
> >>> On 24.02.16 at 16:48, wrote:
> > On 02/24/16 07:24, Jan Beulich wrote:
> >> >>> On 24.02.16 at 14:28, wrote:
> >> > On 02/18/16 10:17, Jan Beulich wrote:
> >> >> >>> On 01.02.16 at 06:44, wrote:
> >> >> > 3.3 Guest ACPI Emulation
> >> >> >
> >> >> > 3
On 02/24/2016 11:42 AM, Haozhong Zhang wrote:
> On 02/24/16 09:00, Ross Philipson wrote:
> [...]
>>> For each NVDIMM device defined in NFIT, there is a ACPI namespace device
>>> (e.g. NVD0, NVD1) under the root NVDIMM device (NVDR). Because the
>>> number of vNVDIMM devices are unknown at build tim
>>> On 24.02.16 at 16:48, wrote:
> On 02/24/16 07:24, Jan Beulich wrote:
>> >>> On 24.02.16 at 14:28, wrote:
>> > On 02/18/16 10:17, Jan Beulich wrote:
>> >> >>> On 01.02.16 at 06:44, wrote:
>> >> > 3.3 Guest ACPI Emulation
>> >> >
>> >> > 3.3.1 My Design
>> >> >
>> >> > Guest ACPI emulation
On 02/24/16 09:00, Ross Philipson wrote:
[...]
> > For each NVDIMM device defined in NFIT, there is a ACPI namespace device
> > (e.g. NVD0, NVD1) under the root NVDIMM device (NVDR). Because the
> > number of vNVDIMM devices are unknown at build time, we can not
> > determine whether and how many N
On 02/24/16 07:24, Jan Beulich wrote:
> >>> On 24.02.16 at 14:28, wrote:
> > On 02/18/16 10:17, Jan Beulich wrote:
> >> >>> On 01.02.16 at 06:44, wrote:
> >> > This design treats host NVDIMM devices as ordinary MMIO devices:
> >>
> >> Wrt the cachability note earlier on, I assume you're aware t
>>> On 24.02.16 at 14:28, wrote:
> On 02/18/16 10:17, Jan Beulich wrote:
>> >>> On 01.02.16 at 06:44, wrote:
>> > This design treats host NVDIMM devices as ordinary MMIO devices:
>>
>> Wrt the cachability note earlier on, I assume you're aware that with
>> the XSA-154 changes we disallow any ca
On 02/24/2016 08:28 AM, Haozhong Zhang wrote:
> On 02/18/16 10:17, Jan Beulich wrote:
> On 01.02.16 at 06:44, wrote:
>>> This design treats host NVDIMM devices as ordinary MMIO devices:
>>
>> Wrt the cachability note earlier on, I assume you're aware that with
>> the XSA-154 changes we disall
On 02/18/16 10:17, Jan Beulich wrote:
> >>> On 01.02.16 at 06:44, wrote:
> > This design treats host NVDIMM devices as ordinary MMIO devices:
>
> Wrt the cachability note earlier on, I assume you're aware that with
> the XSA-154 changes we disallow any cachable mappings of MMIO
> by default.
>
> > > QEMU would always use MFN above guest normal ram and I/O holes for
> > > vNVDIMM. It would attempt to search in that space for a contiguous range
> > > that is large enough for that that vNVDIMM devices. Is guest able to
> > > punch holes in such GFN space?
> >
> > See XENMAPSPACE_* and thei
>>> On 01.02.16 at 06:44, wrote:
> This design treats host NVDIMM devices as ordinary MMIO devices:
Wrt the cachability note earlier on, I assume you're aware that with
the XSA-154 changes we disallow any cachable mappings of MMIO
by default.
> (1) Dom0 Linux NVDIMM driver is responsible to de
On 02/17/16 02:08, Jan Beulich wrote:
> >>> On 17.02.16 at 10:01, wrote:
> > On 02/15/16 04:07, Jan Beulich wrote:
> >> >>> On 15.02.16 at 09:43, wrote:
> >> > On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
> >> >> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> >> >>
>>> On 17.02.16 at 10:01, wrote:
> On 02/15/16 04:07, Jan Beulich wrote:
>> >>> On 15.02.16 at 09:43, wrote:
>> > On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
>> >> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
>> >> > three parts:
>> >> > (1) Guest clwb/clflushopt
On 02/16/16 05:55, Jan Beulich wrote:
> >>> On 16.02.16 at 12:14, wrote:
> > On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
> >> On 02/04/16 20:24, Stefano Stabellini wrote:
> >> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> >> > > On 02/03/16 15:22, Stefano Stabellini wrote:
> >> > > > On Wed, 3 Feb
On 02/15/16 04:07, Jan Beulich wrote:
> >>> On 15.02.16 at 09:43, wrote:
> > On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
> >> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> >> > three parts:
> >> > (1) Guest clwb/clflushopt/pcommit enabling,
> >> > (2) Memory map
>>> On 16.02.16 at 12:14, wrote:
> On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
>> On 02/04/16 20:24, Stefano Stabellini wrote:
>> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
>> > > On 02/03/16 15:22, Stefano Stabellini wrote:
>> > > > On Wed, 3 Feb 2016, George Dunlap wrote:
>> > > > > On 03/02/16
On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
> On 02/04/16 20:24, Stefano Stabellini wrote:
> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> > > On 02/03/16 15:22, Stefano Stabellini wrote:
> > > > On Wed, 3 Feb 2016, George Dunlap wrote:
> > > > > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > >
>>> On 15.02.16 at 09:43, wrote:
> On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
>> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
>> > three parts:
>> > (1) Guest clwb/clflushopt/pcommit enabling,
>> > (2) Memory mapping, and
>> > (3) Guest ACPI emulation.
>>
>>
On 02/03/16 23:47, Konrad Rzeszutek Wilk wrote:
> > > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > > >get the physical address from a virtual address.
> > > > >/proc//pagemap provides information of mapping from
> > > > >VA to PA. Is it an ac
On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
> > 3. Design of vNVDIMM in Xen
>
> Thank you for this design!
>
> >
> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> > three parts:
> > (1) Guest clwb/clflushopt/pcommit enabling,
> > (2) Memory mapping, and
> > (3)
On 02/04/16 20:24, Stefano Stabellini wrote:
> On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> > On 02/03/16 15:22, Stefano Stabellini wrote:
> > > On Wed, 3 Feb 2016, George Dunlap wrote:
> > > > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > > > >
On 02/05/2016 08:43 PM, Haozhong Zhang wrote:
> On 02/05/16 09:40, Ross Philipson wrote:
>> On 02/03/2016 09:09 AM, Andrew Cooper wrote:
> [...]
>>> I agree.
>>>
>>> There has to be a single entity responsible for collating the eventual
>>> ACPI handed to the guest, and this is definitely HVMLoader
On 02/05/16 09:40, Ross Philipson wrote:
> On 02/03/2016 09:09 AM, Andrew Cooper wrote:
[...]
> >I agree.
> >
> >There has to be a single entity responsible for collating the eventual
> >ACPI handed to the guest, and this is definitely HVMLoader.
> >
> >However, it is correct that Qemu create the A
On 02/03/2016 09:09 AM, Andrew Cooper wrote:
On 03/02/16 09:13, Jan Beulich wrote:
On 03.02.16 at 08:00, wrote:
On 02/02/16 17:11, Stefano Stabellini wrote:
Once upon a time somebody made the decision that ACPI tables
on Xen should be static and included in hvmloader. That might have been
a b
On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> On 02/03/16 15:22, Stefano Stabellini wrote:
> > On Wed, 3 Feb 2016, George Dunlap wrote:
> > > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > > >> Or, we can make a file system on /dev/pmem0, create fil
On 02/03/16 14:20, Andrew Cooper wrote:
> > (ACPI part is described in Section 3.3 later)
> >
> > Above (1)(2) have already been done in current QEMU. Only (3) is
> > needed to implement in QEMU. No change is needed in Xen for address
> > mapping in this design.
> >
> >>
On 02/03/16 15:22, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, George Dunlap wrote:
> > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > >> Or, we can make a file system on /dev/pmem0, create files on it, set
> > >> the owner of those files to xen
On 02/03/16 10:47, Konrad Rzeszutek Wilk wrote:
> > > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > > >get the physical address from a virtual address.
> > > > >/proc//pagemap provides information of mapping from
> > > > >VA to PA. Is it an ac
> > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > >get the physical address from a virtual address.
> > > >/proc//pagemap provides information of mapping from
> > > >VA to PA. Is it an acceptable solution to let QEMU parse this
> > > >
On 03/02/16 15:22, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, George Dunlap wrote:
>> On 03/02/16 12:02, Stefano Stabellini wrote:
>>> On Wed, 3 Feb 2016, Haozhong Zhang wrote:
Or, we can make a file system on /dev/pmem0, create files on it, set
the owner of those files to xen-qemuus
On Wed, Feb 03, 2016 at 03:22:59PM +, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, George Dunlap wrote:
> > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > >> Or, we can make a file system on /dev/pmem0, create files on it, set
> > >> the owne
On Wed, 3 Feb 2016, George Dunlap wrote:
> On 03/02/16 12:02, Stefano Stabellini wrote:
> > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> >> Or, we can make a file system on /dev/pmem0, create files on it, set
> >> the owner of those files to xen-qemuuser-domid$domid, and then pass
> >> those files t
On 03/02/16 12:02, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, Haozhong Zhang wrote:
>> Or, we can make a file system on /dev/pmem0, create files on it, set
>> the owner of those files to xen-qemuuser-domid$domid, and then pass
>> those files to QEMU. In this way, non-root QEMU should be able t
>>> On 03.02.16 at 15:30, wrote:
> On 03/02/16 09:18, Jan Beulich wrote:
>>>
In other words - the NVDIMM resource does not provide any resource
isolation. However this may not be any different than what we had
nowadays with CPU caches.
>>> Does Xen have any mechanism to isolate
On 03/02/16 09:18, Jan Beulich wrote:
>>
>>> In other words - the NVDIMM resource does not provide any resource
>>> isolation. However this may not be any different than what we had
>>> nowadays with CPU caches.
>>>
>> Does Xen have any mechanism to isolate multiple guests' operations on
>> CPU cac
On 02/03/16 14:09, Andrew Cooper wrote:
> On 03/02/16 09:13, Jan Beulich wrote:
> On 03.02.16 at 08:00, wrote:
> >> On 02/02/16 17:11, Stefano Stabellini wrote:
> >>> Once upon a time somebody made the decision that ACPI tables
> >>> on Xen should be static and included in hvmloader. That mig
On 03/02/16 13:11, Haozhong Zhang wrote:
> On 02/03/16 12:02, Stefano Stabellini wrote:
>> On Wed, 3 Feb 2016, Haozhong Zhang wrote:
>>> On 02/02/16 17:11, Stefano Stabellini wrote:
On Mon, 1 Feb 2016, Haozhong Zhang wrote:
> [...]
> This design treats host NVDIMM devices as ordinary MMIO
On 03/02/16 09:13, Jan Beulich wrote:
On 03.02.16 at 08:00, wrote:
>> On 02/02/16 17:11, Stefano Stabellini wrote:
>>> Once upon a time somebody made the decision that ACPI tables
>>> on Xen should be static and included in hvmloader. That might have been
>>> a bad decision but at least it wa
On 02/03/16 12:02, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > On 02/02/16 17:11, Stefano Stabellini wrote:
> > > On Mon, 1 Feb 2016, Haozhong Zhang wrote:
[...]
> > > > This design treats host NVDIMM devices as ordinary MMIO devices:
> > > > (1) Dom0 Linux NVDIMM dr
On 02/03/16 05:38, Jan Beulich wrote:
> >>> On 03.02.16 at 13:22, wrote:
> > On 02/03/16 02:18, Jan Beulich wrote:
> >> >>> On 03.02.16 at 09:28, wrote:
> >> > On 02/02/16 14:15, Konrad Rzeszutek Wilk wrote:
> >> >> > 3.1 Guest clwb/clflushopt/pcommit Enabling
> >> >> >
> >> >> > The instructio
1 - 100 of 121 matches
Mail list logo
