> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> The flag is only used for debugging purposes, thus it should be only checked
> for in debug builds of Xen.
>
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/mm/mem_sharing.c | 2 ++
>
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> In preparation for allowing for introspecting ARM and PV domains the old
> control interface via the hvm_op hypercall is retired. A new control
> mechanism
> is introduced via the domctl hyperc
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> To avoid growing hvm.c these functions can be stored
> separately.
>
> Signed-off-by: Tamas K Lengyel
VMX changes are clearly renaming:
Acked-by: Kevin Tian
> ---
> v3: Style fixes and re
> From: Li, Liang Z
> Sent: Wednesday, February 04, 2015 11:28 AM
>
> Flushing cache is needed only when guest has IOMMU device, using
> need_iommu(d) can minimize the impact to guest with device assigned,
> since a guest may be hot plugged with a device thus there may be dirty
> cache lines befor
> From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
> Sent: Tuesday, January 27, 2015 11:06 PM
>
> On Tue, Jan 27, 2015 at 06:41:39AM +, Tian, Kevin wrote:
> > > From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
> > > Sent: Tuesday, January 27, 2
> From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
> Sent: Tuesday, January 27, 2015 1:31 AM
>
> On Mon, Jan 26, 2015 at 05:06:12PM +, Jan Beulich wrote:
> > >>> On 26.01.15 at 17:57, wrote:
> > > On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote:
> > >> >>> On 22.01.15 at
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: Tuesday, January 27, 2015 4:31 AM
>
> The question is about the VM-exit instruction length field.
>
> This is accessed in xen via:
>
>__vmread(VM_EXIT_INSTRUCTION_LEN, &inst_len);
>
> an example of which is in routine get_instruction_len
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 22, 2015 10:01 PM
>
> ... making the code better document itself. No functional change
> intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
___
Xen-devel mailing li
> From: Li, Liang Z
> Sent: Friday, January 23, 2015 1:55 PM
>
> > >>> On 22.01.15 at 08:44, wrote:
> > > Tian, Kevin wrote on 2015-01-22:
> > >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >>> Sent: Wednesday, January 21, 201
> From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
> Sent: Thursday, January 22, 2015 4:53 AM
>
> need_iommu has to be set earler for dom0 pvh specific init
> functions. If not enabled, mmio regions are not mapped with iommu
> during domain construction.
>
> This was discovered when work
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 21, 2015 6:31 PM
>
> >
> > Yes, it's true. But I still don't understand why to do the flush_all just
> > when
> > iommu_enable is true. Could you explain why ?
>
> The question you raise doesn't reflect what the function d
> From: Li, Liang Z
> Sent: Thursday, January 22, 2015 12:29 PM
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, January 21, 2015 7:22 PM
> > To: Li, Liang Z
> > Cc: Andrew Cooper; Dong, Eddie;
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 7:08 PM
>
> ..., yielding better code.
>
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 7:08 PM
>
> Most of them have been unused since the dropping of 32-bit support, and
> the few remaining cases are more efficiently dealt with using a generic
> macro (and probably things should have been done that way
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 7:07 PM
>
> A few relevant control state fields did not get dumped so far; in
> particular, VM_ENTRY_INSTRUCTION_LEN got printed twice (instead of also
> printing VM_EXIT_INSTRUCTION_LEN). Where suitable (to reduce th
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 7:06 PM
>
> Several guest state fields did not get dumped so far. Where suitable
> (to reduce the amount of output) make some of the dumping conditional
> upon guest settings (this isn't required for correctness as vm
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 7:06 PM
>
> A few host state fields did not get dumped so far. Where suitable (to
> reduce the amount of output) make some of the dumping conditional upon
> guest settings (this isn't required for correctness as vmr()
> From: George Dunlap
> Sent: Tuesday, January 20, 2015 8:57 PM
>
> On Tue, Jan 20, 2015 at 12:52 AM, Tian, Kevin wrote:
> >> For RMRRs in the BIOS area, libxl will already need to know where that
> >> area is (to know that it doesn't need to fit it into the
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 6:49 PM
>
> >>> On 20.01.15 at 11:38, wrote:
> > On Tue, 2015-01-20 at 09:10 +, Jan Beulich wrote:
> >> >>> On 20.01.15 at 09:59, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Tuesda
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 3:29 PM
>
> >>> On 20.01.15 at 01:45, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> The proposed new hypercall represents _only_ reserved regions.
> >> But it was said several times that making the e
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 4:43 PM
>
> >>> On 20.01.15 at 01:52, wrote:
> > We may make a reasonable simplification to treat all RMRRs <1MB as
> > conflicts (all real observations so far are in BIOS region).
>
> I'm not really agreeing to thi
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Monday, January 19, 2015 9:01 PM
>
> On 01/19/2015 12:23 PM, Tim Deegan wrote:
> > At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> > On 19.01.15 at 12:33, wrote:
> >>> FWIW, I don't like adding hypervisor state (an
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 19, 2015 9:52 PM
>
> >>> On 19.01.15 at 13:23, wrote:
> > At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> >> >>> On 19.01.15 at 12:33, wrote:
> >> > FWIW, I don't like adding hypervisor state (and even more so
> >
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 19, 2015 5:33 PM
>
> >>> On 18.01.15 at 09:58, wrote:
> > still one open to hear suggestion though, regarding to how we want
> > to pass the reserved regions to domain builder and hvmloader (for Xen
> > we will extend related
> From: George Dunlap
> Sent: Thursday, January 15, 2015 7:45 PM
>
> >
> > If above high level flow can be agreed, then we can move forward to
> > discuss next level detail e.g. how to pass the rmrr list cross different
> > components. :-)
>
> I think we're definitely ready to move on. There are
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 15, 2015 6:06 PM
>
> > The composed reserved region list is then passed to domain builder,
> > which tries to detect and avoid conflicts when populating guest RAM.
> > To avoid breaking lowmem/highmem layout, we can define a
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 15, 2015 4:38 PM
>
> >>> On 14.01.15 at 19:29, wrote:
> > Just to be clear -- what we're talking about here is that at the
> > do_domain_create() level (called by libxl_domain_create_new()), it will
> > take a list of pci de
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 11:08 PM
>
> >>> On 14.01.15 at 13:17, wrote:
> > On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> >> - RMRRs conflicting with guest BIOS in <1MB area, as an example
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Thursday, January 15, 2015 2:22 AM
>
> On 01/14/2015 02:42 PM, Jan Beulich wrote:
> >>>> On 14.01.15 at 13:29, wrote:
> >> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> >>> We d
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:23 PM
>
> On 01/14/2015 12:14 PM, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
>
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, January 15, 2015 4:43 AM
>
> On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: Wednes
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:02 PM
>
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
> On 14.01.15 at 10:43, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Wednesday, January 14, 2015 5:00 PM
> >>>
> >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 6:24 PM
>
> >>> On 14.01.15 at 10:43, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, January 14, 2015 5:00 PM
> >>
> >> >>> On 14.01.15 at 09:06, wrote:
> >> > Now the open is whet
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:03 PM
>
> >>> On 14.01.15 at 09:13, wrote:
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> >> Sent: Wednesday, January 14, 2015 12:46 AM
> >>
> >> Perhaps an easier way of this is to use the e
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:00 PM
>
> >>> On 14.01.15 at 09:06, wrote:
> > Now the open is whether we want to fail domain creation for all of above
> > conflicts. user may choose to bear with conflicts at his own disposal, or
> > libxl does
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, January 14, 2015 12:46 AM
>
>
> Perhaps an easier way of this is to use the existing
> mechanism we have - that is the XENMEM_memory_map (which
> BTW e820_host uses). If all of this is done in the libxl (which
> alre
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Tuesday, January 13, 2015 11:59 PM
>
> On 01/13/2015 03:52 PM, Jan Beulich wrote:
> On 13.01.15 at 13:03, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Tuesday, January 13, 2015 7:56 PM
> >> On 13
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 12:06 AM
>
> >>> On 13.01.15 at 17:00, wrote:
> > Another option I was thinking about: Before assigning a device to a
> > guest, you have to unplug the device and assign it to pci-back (e.g.,
> > with xl pci-assign
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 13, 2015 7:56 PM
>
> >>> On 13.01.15 at 12:03, wrote:
> > Then I hope you understand now about our discussion in libxl/xen/
> > hvmloader, based on the fact that conflict may not be avoided.
> > That's the major open in origi
> From: George Dunlap
> Sent: Monday, January 12, 2015 10:20 PM
>
> On Mon, Jan 12, 2015 at 12:28 PM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Monday, January 12, 2015 8:14 PM
> >>
> >> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, January 12, 2015 9:42 PM
>
> On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> > 3) report-sel vs. report-all
>
> One thing I'm not clear on is whether you are suggesting to reserve RMRR
>
> From: Tian, Kevin
> Sent: Monday, January 12, 2015 8:29 PM
>
> > From: George Dunlap
> > Sent: Monday, January 12, 2015 8:14 PM
> >
> > On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin
> wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.co
> From: George Dunlap
> Sent: Monday, January 12, 2015 8:14 PM
>
> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >>
> >> >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 8:03 PM
>
> >>> On 12.01.15 at 12:41, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 7:37 PM
> >>
> >> >>> On 12.01.15 at 12:22, wrote:
> >> >> From: Jan Beulich [mailt
> From: Stefano Stabellini
> Sent: Monday, January 12, 2015 7:36 PM
>
> On Wed, 24 Dec 2014, Liang Li wrote:
> > Use the 'xl pci-attach $DomU $BDF' command to attach more then
> > one PCI devices to the guest, then detach the devices with
> > 'xl pci-detach $DomU $BDF', after that, re-attach these
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 7:37 PM
>
> >>> On 12.01.15 at 12:22, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >> One of my main problems with all you recent argumentation here
> >> is t
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 6:23 PM
>
> >>> On 12.01.15 at 11:12, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:09 PM
> >>
> >> >>> On 12.01.15 at 10:56, wrote:
> >> > the result is related to a
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 6:09 PM
>
> >>> On 12.01.15 at 10:56, wrote:
> > the result is related to another open whether we want to block guest
> > boot for such problem. If 'warn' in domain builder is acceptable, we
> > don't need to change l
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 5:51 PM
>
> >>> On 12.01.15 at 10:41, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 5:33 PM
> >> >>> On 12.01.15 at 09:46, wrote:
> >> >> From: Jan Beulich [mailto:jbe
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Saturday, January 10, 2015 4:28 AM
>
> On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > On 08.01.15 at 16:59, wrote:
> > >> On Thu, Jan 8, 2015 at 1
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 5:33 PM
>
> >>> On 12.01.15 at 09:46, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, January 09, 2015 6:35 PM
> >> >>> On 09.01.15 at 11:10, wrote:
> >> >> From: Jan Beulich [mailto:jbe
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 6:46 PM
>
> >>> On 09.01.15 at 11:26, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >>> On 09.01.15 at 07:57, wrote:
> >> > 1.1) per-device 'warn' vs. global 'warn'
> >> >
> >> > Both Tim/Jan prefer
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 6:35 PM
>
> >>> On 09.01.15 at 11:10, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Boot time device assignment is different: The question isn't whether
> >> an assigned device works, instead the prop
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 5:46 PM
>
> >>> On 09.01.15 at 07:57, wrote:
> > 1) 'fail' vs. 'warn' upon gfn confliction
> >
> > Assigning device which fails RMRR confliction check (i.e. intended gfns
> > already allocated for other resources) act
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 5:21 PM
>
> >>> On 09.01.15 at 03:27, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, January 08, 2015 9:55 PM
> >> >>> On 26.12.14 at 12:23, wrote:
> >> > 3) hvmloader
> >> > Hvmload
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 09, 2015 5:24 PM
>
> >>> On 09.01.15 at 03:29, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, January 08, 2015 8:59 PM
> >>
> >> >>> On 08.01.15 at 13:49, wrote:
> >> > One question: where are
> 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
t still needs handle confliction anyway.
The other is to let libxc only populate a small RAM necessary to bring up
hvmloader and then have hvmloader do the bulk populating. again, such
change is not small and earlier suggestion on lowmem assumption is more
reasonable.
--
(there are other good comment
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, January 08, 2015 11:39 PM
>
> Use the standard "do { } while ( 0 )" semantics, and don't hide the break
> statement, incase this macro wants to be used anywhere outside of a switch.
>
> No functional change, but it is now
> From: George Dunlap
> Sent: Friday, January 09, 2015 2:02 AM
>
> On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> On 08.01.15 at 16:59, wrote:
> >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote:
> the 1st invocation of this interface will save all reported reserved
> re
> From: George Dunlap
> Sent: Friday, January 09, 2015 12:00 AM
>
> >3.3 Policies
> >>
> >> An intuitive thought is to fail immediately upon a confliction, however
> >> it is not flexible regarding to different requirments:
> >>
> >> a) it's not appropriate to fail libxc domain builder ju
> From: George Dunlap
> Sent: Thursday, January 08, 2015 8:55 PM
>
> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
> wrote:
> > If RMRRs almost always happen up above 2G, for example, then a simple
> > solution that wouldn't require too much work would be to make sure
> > that the PCI MMIO hole
> From: George Dunlap
> Sent: Thursday, January 08, 2015 8:50 PM
>
> On Fri, Dec 26, 2014 at 11:23 AM, Tian, Kevin wrote:
> > (please note some proposal is different from last sent version after more
> > discussions. But I tried to summarize previous discussions and expla
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 08, 2015 8:59 PM
>
> >>> On 08.01.15 at 13:49, wrote:
> > One question: where are these RMRRs typically located in memory? Are
> > they normally up in the MMIO region? Or can they occur anywhere (even
> > in really low are
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 08, 2015 9:55 PM
>
> >>> On 26.12.14 at 12:23, wrote:
> > [Issue-2] Being lacking of goal-b), existing device assignment with
> > RMRR works only when reserved regions happen to not conflicting with
> > other valid allocatio
he tools desig to others...
>
> At 11:23 +0000 on 26 Dec (1419589382), Tian, Kevin wrote:
> > c) in Xen hypervisor it is reasonable to fail upon confliction, where
> > device is actually assigned. But due to the same requirement on USB
> > controller, sometimes we might want it suc
Ping in case this mail is hidden after long holiday. :-)
> From: Tian, Kevin
> Sent: Friday, December 26, 2014 7:23 PM
>
> (please note some proposal is different from last sent version after more
> discussions. But I tried to summarize previous discussions and explained wh
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 07, 2015 6:16 PM
>
> >>> On 23.12.14 at 07:52, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, December 19, 2014 7:26 PM
> >>
> >> This can (and will) be legitimately the case when sharing page
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Tuesday, January 06, 2015 12:33 AM
>
> On Thu, Dec 18, 2014 at 01:06:40PM -0500, Boris Ostrovsky wrote:
> > We need to make sure that last_vcpu is not pointing to VCPU whose
> > VPMU is being destroyed. Otherwise we may try to d
> 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
> 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).
(please note some proposal is different from last sent version after more
discussions. But I tried to summarize previous discussions and explained why
we choose a different way. Sorry if I may miss some opens/conclusions
discussed in past months. Please help point it out which is very appreciated.
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 19, 2014 7:26 PM
>
> This can (and will) be legitimately the case when sharing page tables
> with EPT (more of a problem before p2m_access_rwx became zero, but
> still possible even now when other than that is the default for
I'll work out a new design proposal based on below content and previous
discussions. Thanks Tiejun for your hard-working and Jan for your careful
reviews so far.
For below comment:
> > Also there's clearly an alternative proposal: Drop support for sharing
> > page tables. Your colleagues will sure
> 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
> 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?)
> >> >
> 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
> 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&#x
> 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, X
> 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
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Wednesday, December 10, 2014 7:12 PM
>
> Hi Kevin,
>
> Thanks for taking the time to work through this.
>
> At 03:39 + on 10 Dec (1418179184), Tian, Kevin wrote:
> > 1. It's more efficient for new people
> 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 w
> 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
> > >
> >
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 10, 2014 5:01 PM
>
> >>> On 10.12.14 at 04:39, wrote:
> > 1. It's more efficient for new people to start from a small, well-defined
> > task
> > in one area, and then spanning to adjacent areas gradually. Patience must
> >
> 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
> 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:jbeu
> 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
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 08, 2014 5:13 PM
>
> PVH guests accessing I/O ports via string ops is not supported yet.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
> ---
> v2: handle_pio() is already safe (pointed
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Tuesday, December 09, 2014 6:11 PM
>
> At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
> > Why do you always pick other than the simplest possible solution?
>
> Jan, please don't make personal comments like this in code review. It
> can
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, December 09, 2014 7:44 PM
>
> > -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-de
> 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
> From: Don Dugger [mailto:n0...@n0ano.com]
> Sent: Friday, December 05, 2014 2:13 PM
>
> On Fri, Dec 05, 2014 at 05:30:52AM +, Tian, Kevin wrote:
> > > From: Donald D. Dugger
> > > Sent: Friday, November 21, 2014 1:12 PM
> > >
> > > Curre
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 05, 2014 12:29 AM
>
> >>> On 01.12.14 at 10:24, wrote:
> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> > to allocate some memory to use in runtime cycle, so we alsoe need to
> > make sure all reser
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 05, 2014 12:20 AM
>
> >>> On 01.12.14 at 10:24, wrote:
> > We need to check to reserve all reserved device memory maps in e820
> > to avoid any potential guest memory conflict.
> >
> > Currently, if we can't insert RDM entrie
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 04, 2014 11:33 PM
> > +if ( pcidevs == NULL )
> > +{
> > +rcu_unlock_domain(d);
> > +return -ENOMEM;
> > +}
> > +
> > +if ( copy_from_guest(pcide
> From: Donald D. Dugger
> Sent: Friday, November 21, 2014 1:12 PM
>
> Currently the quirk code for SandyBridge uses the VTd timeout value when
> writing to an IGD register. This is the wrong timeout to use and, at
> 1000 msec., is also much too large. This patch changes the quirk code
> to use
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: Thursday, December 04, 2014 6:20 PM
>
> Il 04/12/2014 03:45, Jike Song ha scritto:
> > Hi all,
> >
> > We're pleased to announce a public release to Intel Graphics
> > Virtualization Technology (Intel GVT-g, formerly known as XenGT).
> >
801 - 900 of 920 matches
Mail list logo
