[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT
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?
Without these two patches, any assigned device with RMRR dependency
can't work at all since RMRR table never be created. But if we apply
these two patches, RMRR table can be created safely, right? Then the
assigned device can work based on them.
Thanks
Tiejun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
