[Xen-ia64-devel] RE: Fix one issue when assigning device with 64-bit bars.
We only found it when assigning the device with vt-d. Since qemu doesn't have the device with 64-bit bars, so maybe no issue. Xiantao Tristan Gingold wrote: > On Tue, Mar 03, 2009 at 01:47:49PM +0800, Zhang, Xiantao wrote: >> Hi, Tristan >> Attached patch targets for fixing the issue when assigning the >> devices with 64-bit bars. Current logic may deem one 64-bit bar as >> two 32-bit bars, and make the system crash finally. > > Merged, thanks! > > Do you meet the issue with qemu or with VTD devices ? > > Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Fix one issue when assigning device with 64-bit bars.
On Tue, Mar 03, 2009 at 01:47:49PM +0800, Zhang, Xiantao wrote: > Hi, Tristan > Attached patch targets for fixing the issue when assigning the devices > with 64-bit bars. Current logic may deem one 64-bit bar as two 32-bit bars, > and make the system crash finally. Merged, thanks! Do you meet the issue with qemu or with VTD devices ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
On Tue, Mar 03, 2009 at 05:32:42PM +0800, Zhang, Xiantao wrote:
>
> Isaku Yamahata wrote:
> > Could you elaborate on the concrete issue which you're seeing?
> > I guess the issue occurs when passed through pci device
> > is unplugged. But in that case, the region was occupied by
> > the device so that qemu haven't seen io on the area anyway.
>
> For assigning a device to a hvm domain, all mmio regions of the pci device
> should be mapped in p2m table, but a corner case is that accessing some
> pages(for example, vector table in msi-x's bar) in one region maybe need
> route to qemu and emulate the corresponding logic in qemu. In that case, we
> have to remove the mapping for the specified pages in p2m, and let accessing
> these pages intercepted by hyperviosr and forward the io requests to qemu.
> But zap_domain_page_one can't intilziate the mmio p2m entries for hvm domain.
> Clear ? :-)
You mean pt_iomem_map() which calls remove_msix_mapping() in
pass-through.c of qemu-dm? Is there any case other than msi-x?
I couldn't find any other usefull case because the current xen/ia64
doesn't support msi/msi-x.
> > And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
> > of io_ranges[]?
>
> For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO
> combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges.
> You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to
> intialize p2m entries for low mmio range.
Hmm, there are two cases to call xc_domain_mempry_mapping(DPCI_REMOVE_MAPPING).
- Just to remove the entry.
zap_domain_page_one() is wanted.
the one in pt_iomem_map() and remove_msix_mapping() excpet called
by pt_iomem_map()
- mmio on the area should be rounted to qemu-dm
GPFN_LOW_MMIO and ASSIGN_io are wanted.
remove_msix_mapping() which is called by pt_iomem_map().
Is there a way to distinguish them?
thanks,
> Xiantao
>
> >
> > On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote:
> >> PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
> >>
> >> When de-assign the mmio range, it should resume its original value
> >> for p2m value, otherwise, it may fail to determin mmio range's type.
> >>
> >> Signed-off-by: Xiantao Zhang
> >>
> >> diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
> >> --- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800
> >> +++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800
> >> @@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
> >> return -EINVAL; }
> >>
> >> -for (; addr < end; addr += PAGE_SIZE )
> >> -zap_domain_page_one(d, addr, 0, INVALID_MFN);
> >> +for (; addr < end; addr += PAGE_SIZE ) {
> >> + if (is_hvm_domain(d))
> >> +__assign_domain_page(d, addr, GPFN_LOW_MMIO <<
> >> PAGE_SHIFT, +
> >> ASSIGN_writable |
> >> ASSIGN_io); + else +zap_domain_page_one(d, addr, 0,
> >> INVALID_MFN); +} +
> >> return 0;
> >> }
> >>
> >
> >> ___
> >> Xen-ia64-devel mailing list
> >> Xen-ia64-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-ia64-devel
>
>
> ___
> Xen-ia64-devel mailing list
> Xen-ia64-devel@lists.xensource.com
> http://lists.xensource.com/xen-ia64-devel
>
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote:
> Could you elaborate on the concrete issue which you're seeing?
> I guess the issue occurs when passed through pci device
> is unplugged. But in that case, the region was occupied by
> the device so that qemu haven't seen io on the area anyway.
For assigning a device to a hvm domain, all mmio regions of the pci device
should be mapped in p2m table, but a corner case is that accessing some
pages(for example, vector table in msi-x's bar) in one region maybe need route
to qemu and emulate the corresponding logic in qemu. In that case, we have to
remove the mapping for the specified pages in p2m, and let accessing these
pages intercepted by hyperviosr and forward the io requests to qemu. But
zap_domain_page_one can't intilziate the mmio p2m entries for hvm domain.
Clear ? :-)
> And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
> of io_ranges[]?
For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO
combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges.
You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to intialize
p2m entries for low mmio range.
Xiantao
>
> On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote:
>> PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
>>
>> When de-assign the mmio range, it should resume its original value
>> for p2m value, otherwise, it may fail to determin mmio range's type.
>>
>> Signed-off-by: Xiantao Zhang
>>
>> diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
>> --- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800
>> +++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800
>> @@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
>> return -EINVAL; }
>>
>> -for (; addr < end; addr += PAGE_SIZE )
>> -zap_domain_page_one(d, addr, 0, INVALID_MFN);
>> +for (; addr < end; addr += PAGE_SIZE ) {
>> +if (is_hvm_domain(d))
>> +__assign_domain_page(d, addr, GPFN_LOW_MMIO <<
>> PAGE_SHIFT, +
>> ASSIGN_writable |
>> ASSIGN_io); +else +zap_domain_page_one(d, addr, 0,
>> INVALID_MFN); +} +
>> return 0;
>> }
>>
>
>> ___
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@lists.xensource.com
>> http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Could you elaborate on the concrete issue which you're seeing?
I guess the issue occurs when passed through pci device
is unplugged. But in that case, the region was occupied by
the device so that qemu haven't seen io on the area anyway.
And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
of io_ranges[]?
thanks,
On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote:
> PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
>
> When de-assign the mmio range, it should resume its original value
> for p2m value, otherwise, it may fail to determin mmio range's type.
>
> Signed-off-by: Xiantao Zhang
>
> diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
> --- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800
> +++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800
> @@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
> return -EINVAL;
> }
>
> -for (; addr < end; addr += PAGE_SIZE )
> -zap_domain_page_one(d, addr, 0, INVALID_MFN);
> +for (; addr < end; addr += PAGE_SIZE ) {
> + if (is_hvm_domain(d))
> +__assign_domain_page(d, addr, GPFN_LOW_MMIO << PAGE_SHIFT,
> +ASSIGN_writable | ASSIGN_io);
> + else
> +zap_domain_page_one(d, addr, 0, INVALID_MFN);
> +}
> +
> return 0;
> }
>
> ___
> Xen-ia64-devel mailing list
> Xen-ia64-devel@lists.xensource.com
> http://lists.xensource.com/xen-ia64-devel
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
