Applied, thanks.
On Fri, Oct 24, 2008 at 11:02:21AM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Thu, Oct 23, 2008 at 03:10:55PM +0800, Xu, Anthony wrote:
> >> The new one,
> >
> > It looks almost okay. The last one.
> >
> >
> >> diff -r 02c8733e2d91 xen/arch/ia64/vmx/viosapic.c
> >
Isaku Yamahata wrote:
> On Thu, Oct 23, 2008 at 03:10:55PM +0800, Xu, Anthony wrote:
>> The new one,
>
> It looks almost okay. The last one.
>
>
>> diff -r 02c8733e2d91 xen/arch/ia64/vmx/viosapic.c
>> --- a/xen/arch/ia64/vmx/viosapic.c Wed Oct 22 17:20:15 2008 +0900
>> +++ b/xen/arch/ia64/vmx/
On Thu, Oct 23, 2008 at 03:10:55PM +0800, Xu, Anthony wrote:
> The new one,
It looks almost okay. The last one.
> diff -r 02c8733e2d91 xen/arch/ia64/vmx/viosapic.c
> --- a/xen/arch/ia64/vmx/viosapic.cWed Oct 22 17:20:15 2008 +0900
> +++ b/xen/arch/ia64/vmx/viosapic.cThu Oct 23 14:48:09 2
The new one,
Thanks,
Anthony
Isaku Yamahata wrote:
> On Thu, Oct 23, 2008 at 10:31:20AM +0800, Xu, Anthony wrote:
>> Iommu_un/map_page does nothing for PV domain.
>> Why is there a race?
>
> Oh sorry. I'm not very familiar with iommu code (yet).
> My understanding is
> iommu_domain_init() is
Hi shimura
I only tested in old version 18134.
I can reproduce it.
And I find another way to handle it,
Will send out patch soon.
Thanks,
anthony
Kouya Shimura wrote:
> Hi Anthony,
>
> Xu, Anthony writes:
-if (phy_pte.ma != VA_MATTR_NATPAGE)
+/* if a device is assigned to a do
Xu, Anthony wrote:
> Isaku Yamahata wrote:
>> On Thu, Oct 23, 2008 at 10:31:20AM +0800, Xu, Anthony wrote:
>>> Iommu_un/map_page does nothing for PV domain.
>>> Why is there a race?
>>
>> Oh sorry. I'm not very familiar with iommu code (yet).
>> My understanding is
>> iommu_domain_init() is calle
Isaku Yamahata wrote:
> On Thu, Oct 23, 2008 at 10:31:20AM +0800, Xu, Anthony wrote:
>> Iommu_un/map_page does nothing for PV domain.
>> Why is there a race?
>
> Oh sorry. I'm not very familiar with iommu code (yet).
> My understanding is
> iommu_domain_init() is called unconditionaly by arch_dom
On Thu, Oct 23, 2008 at 10:31:20AM +0800, Xu, Anthony wrote:
> Iommu_un/map_page does nothing for PV domain.
> Why is there a race?
Oh sorry. I'm not very familiar with iommu code (yet).
My understanding is
iommu_domain_init() is called unconditionaly by arch_domain_create()
so that platform_o
Isaku Yamahata wrote:
> On Thu, Oct 23, 2008 at 10:03:55AM +0800, Xu, Anthony wrote:
>> Isaku Yamahata wrote:
>>> On Wed, Oct 22, 2008 at 05:35:36PM +0800, Xu, Anthony wrote:
The new one,
>> -if (phy_pte.ma != VA_MATTR_NATPAGE)
>> +/* if a device is assigned to a doma
On Thu, Oct 23, 2008 at 10:03:55AM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 2008 at 05:35:36PM +0800, Xu, Anthony wrote:
> >> The new one,
> >>
> >>
> -if (phy_pte.ma != VA_MATTR_NATPAGE)
> +/* if a device is assigned to a domain through VTD, the MMIO
Isaku Yamahata wrote:
> On Wed, Oct 22, 2008 at 05:35:36PM +0800, Xu, Anthony wrote:
>> The new one,
>>
>>
-if (phy_pte.ma != VA_MATTR_NATPAGE)
+/* if a device is assigned to a domain through VTD, the MMIO
for this + * device needs to retain to UC attribute + */
On Wed, Oct 22, 2008 at 05:35:36PM +0800, Xu, Anthony wrote:
> The new one,
>
>
> >> -if (phy_pte.ma != VA_MATTR_NATPAGE)
> >> +/* if a device is assigned to a domain through VTD, the MMIO
> >> for this + * device needs to retain to UC attribute
> >> + */
> >> +if (phy_pte.ma
Hi Anthony,
Xu, Anthony writes:
> >> -if (phy_pte.ma != VA_MATTR_NATPAGE)
> >> +/* if a device is assigned to a domain through VTD, the MMIO
> >> for this + * device needs to retain to UC attribute
> >> + */
> >> +if (phy_pte.ma == VA_MATTR_WC)
> >> phy_pte.ma = VA_MAT
The new one,
>> -if (phy_pte.ma != VA_MATTR_NATPAGE)
>> +/* if a device is assigned to a domain through VTD, the MMIO
>> for this + * device needs to retain to UC attribute
>> + */
>> +if (phy_pte.ma == VA_MATTR_WC)
>> phy_pte.ma = VA_MATTR_WB;
>>
>
> Doesn't this bre
On Wed, Oct 22, 2008 at 02:50:40PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 2008 at 02:30:50PM +0800, Xu, Anthony wrote:
> >> Isaku Yamahata wrote:
> >>> On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 20
Isaku Yamahata wrote:
> On Wed, Oct 22, 2008 at 02:30:50PM +0800, Xu, Anthony wrote:
>> Isaku Yamahata wrote:
>>> On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
Isaku Yamahata wrote:
> On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
>> Yes, it is not SMP-safe
On Wed, Oct 22, 2008 at 02:30:50PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
> >> Isaku Yamahata wrote:
> >>> On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
> Yes, it is not SMP-safe there is lock for p2m.
>
Isaku Yamahata wrote:
> On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
>> Isaku Yamahata wrote:
>>> On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
Yes, it is not SMP-safe there is lock for p2m.
Modifying p2m is not a frequent operation, why not add a lock for
>
On Wed, Oct 22, 2008 at 02:11:52PM +0800, Xu, Anthony wrote:
> Isaku Yamahata wrote:
> > On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
> >> Yes, it is not SMP-safe there is lock for p2m.
> >> Modifying p2m is not a frequent operation, why not add a lock for it?
> >
> > It is frequent
Isaku Yamahata wrote:
> On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
>> Yes, it is not SMP-safe there is lock for p2m.
>> Modifying p2m is not a frequent operation, why not add a lock for it?
>
> It is frequent to read p2m table. So lockless approach was adopted
> for scalability.
>
On Wed, Oct 22, 2008 at 01:56:05PM +0800, Xu, Anthony wrote:
> >> diff -r e1ed3e5cd001 xen/arch/ia64/xen/mm.c
> >> --- a/xen/arch/ia64/xen/mm.c Tue Oct 21 18:55:22 2008 +0800
> >> +++ b/xen/arch/ia64/xen/mm.c Tue Oct 21 19:13:45 2008 +0800 @@
> >> -189,6 +189,10 @@
> >>
> >> static void __xencom
Isaku Yamahata wrote:
> Doesn't this break the intention of the c/s 15134:466f71b1e831?a
> To be honest, I'm not sure. Kyouya or Akio, do you have any comments?
>
>
>> maddr = ((maddr & _PAGE_PPN_MASK) & PAGE_MASK) | (paddr &
>> ~PAGE_MASK);
>> diff -r e1ed3e5cd001 xen/arch/ia64/xen/domain.c
>
[I added Kyouya and Akio to CC for comments on the hunk in vtlb.c]
On Tue, Oct 21, 2008 at 07:38:21PM +0800, Xu, Anthony wrote:
> other small patches for VTD
>
> Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
>
>
> This patch is based on #Cset 18673 of xen-devel
>
> Thanks,
> Anthony
The pat
23 matches
Mail list logo
