Re: [Xen-devel] [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, September 23, 2014 5:14 AM
> 
> >>> On 23.09.14 at 03:56, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2014/9/22 18:36, Jan Beulich wrote:
> >>>>> On 22.09.14 at 11:05, <tiejun.chen@xxxxxxxxx> wrote:
> >>> On 2014/9/22 16:53, Jan Beulich wrote:
> >>>>>>> On 22.09.14 at 07:46, <tiejun.chen@xxxxxxxxx> wrote:
> >>>>>>     >> It should suffice to give 3 Gb (or event slightly less) of
> memory to
> >>>>>>    >> the DomU (if your Dom0 can hopefully tolerate running with
> just 1Gb).
> >>>>>>    >
> >>>>>>    > Yes. So I can't produce that real case of conflict with those
> existing
> >>>>>>    > RMRR in my platform.
> >>>>>>
> >>>>>> When you pass 3Gb to the guest, its memory map should extend to
> >>>>>> about 0xC0000000, well beyond the range the RMRRs reference. So
> >>>>>
> >>>>> Yes. So I set memory size as 2816M which also cover all RMRR ranges
> in
> >>>>> my platform.
> >>>>>
> >>>>>> you ought to be able to see the collision (or if you don't you ought to
> >>>>>> have ways to find out why they're not happening, as that would be a
> >>>>>> sign of something else being bogus).
> >>>>>>
> >>>>>
> >>>>> Then I can see that work as we expect:
> >>>>>
> >>>>> # xl cr hvm.cfg
> >>>>> Parsing config from hvm.cfg
> >>>>> libxl: error: libxl_pci.c:949:do_pci_add: xc_assign_device failed:
> >>>>> Operation not permitted
> >>>>> libxl: error: libxl_create.c:1329:domcreate_attach_pci:
> >>>>> libxl_device_pci_add failed: -3
> >>>>>
> >>>>> And
> >>>>>
> >>>>> # xl dmesg
> >>>>> ...
> >>>>> (XEN) [VT-D]iommu.c:1589: d0:PCI: unmap 0000:00:02.0
> >>>>> (XEN) [VT-D]iommu.c:1452: d1:PCI: map 0000:00:02.0
> >>>>> (XEN) Cannot identity map d1:ad000, already mapped to 115d51.
> >>>>> (XEN) [VT-D]iommu.c:2296: IOMMU: mapping reserved region failed
> >>>>> (XEN) XEN_DOMCTL_assign_device: assign 0000:00:02.0 to dom1 failed
> (-1)
> >>>>> (XEN) [VT-D]iommu.c:1589: d1:PCI: unmap 0000:00:02.0
> >>>>> (XEN) [VT-D]iommu.c:1452: d0:PCI: map 0000:00:02.0
> >>>>> ...
> >>>>
> >>>> So after all device assignment fails in that case, which is what I was
> >>>> expecting to happen. Which gets me back to the question: What's
> >>>> the value of the two patches for you if with them you can't pass
> >>>> through anymore the device you want passed through for the actual
> >>>> work you're doing?
> >>>
> >>> I don't understand what you mean again. This is true we already known
> >>> previously because this is just a part of the whole solution, right? So
> >>> I can't understand why we can't apply them now unless you're saying
> >>> they're wrong.
> >>
> >> You want these two patches applied despite having acknowledged
> >> that even for you they cause a regression (at the very least an
> >> apparent one).
> >>
> >
> > Why did you say this is a regression?
> 
> Did things work for you _regardless_ of guest memory size?
> 
> > Without these two patches, any assigned device with RMRR dependency
> > can't work at all since RMRR table never be created.
> 
> Whether a device works without the RMRR being mapped is an
> unknown without knowing the specifics of the device - see USB
> devices which don't normally need these regions post boot.
> 
> > But if we apply
> > these two patches, RMRR table can be created safely, right? Then the
> > assigned device can work based on them.
> 
> As long as the guest has little enough memory. As said before, if
> the RMRR specifies regions below 1Mb, I don't think you'll be able
> to create any guest with a respective device passed through.
> 

Hi, Jan,

I'm a bit lost what's the exact regression here. This patch definitely is not 
aimed
to solve all the problems, which is what Tiejun's another big series is doing. 
it's
a step forward to allow GPU pass-through for Windows VM, w/o regression in 
other areas (which are mostly broken today). However, seems your regression
is caused by patching other code:

----
So I gave this a try on the one box I have which exposes RMRRs
(since those are for USB devices I also used your patch to drop
the USB special casing as done in your later patch series, and I
further had to fiddle with vtd_ept_page_compatible() in order to
get page table sharing to actually work on that box [I'll send the
resulting patch later])
----

If that's the case, it's not the regression typically defined.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel