| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] [RFC] grant table API clean up and performancetunin
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年3月28日 17:50
>
>Hi Kevin. Thanks for your comment.
>Please note that I listed these ideas for discussion.
>I don't necessary have concreate implementation idea about them.
>Some might be good, some might be bad.
Definitely. Discussion makes things clear. :-)
>>
>> Since frame within grant table entry is gmfn and xen is aware whether this
>> gmfn
>> equals to mfn or not, there's no need to change concept of host_addr and you
>> can
>> just deliver a dummy va address.
>
>I agree. I had a vague similar model in my mind
>You made it very clear.
>I guess that grant table on translate x86 isn't supported yet, right?
The grant table exists on current translate x86. From virtual driver code,
there're places checking against translated mode. I'm not sure about dom0,
but for domU, the grant table gpfns are kept adjacent to console gpfn by
control panel.
I sent out a question about current status of translated mode on xen-devel
and you may follow up with further questions.
>
>> How about record read-only property in the p2m table of that domain? Later
>> when
>> inserting entry into VHPT table and mTLB, p2m entry can be checked to set
>read-only
>> flag.
>
>I meant the P2M table by
>'Xen/IA64 software address translation page table'
>so that you and I reached the same conclusion.
Yes, and sorry for misunderstanding here.
>
>> >- trust privileged domains
>> > Xen/IA64 trust privileged domain(dom0) to flush tlb cache.
>>
>> What do you mean by "trust"? Purge instruction still traps to xen since
>> xenlinux is
>> running as less privilege level. Maybe I didn't understand your point here.
>
>When a granted page is unmapped or a page is disassociated
>from pseudo physical address, xen/IA64 must flush tlb/VHPT.
>Otherwise it might be possible for a malicious domain to read/write
>the page using unflushed virtual address after the page is recyecled
>and used for other purpose.
>If we assume that dom0 isn't malicious so that it issues
>appropriate tlb flush after unmapping/disassociating and doesn't read/write
>a unmapped/disassociated page, then we can skip tlb/VHPT flush in xen/IA64
>when unmapping/disassociating.
I'm not sure whether we can really gain even by trusting dom0. Aside from
more context switches added (since flush request starts from dom0), you
still need to flush tlb/VHPT on all LPs that dom0 is running on. It's natural
to say that dom0 has one vcpu on each LP (current x86 guest SMP model),
and in that case, once xen receives flush request from dom0, tlb/VHPT flush
is required on all LPs for specified range... Is there any more difference
except
flush time? :-)
Thanks,
Kevin
>
>This is a trade-off between performance and security so this
>should be the last one which is evaluated.
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home