Re: [Xen-ia64-devel] Faulty protection key handling
Tristan Gingold wrote: On Wed, Apr 25, 2007 at 03:36:20PM +0200, Dietmar Hahn wrote: Hi, [..] By the way, are there any thoughts about adding emulation of protection keys to the hypervisor? I know, whether the hypervisor nor dom0-linux are using this but we need this stuff. I would try to write a proposal and add using protection keys in the minios for tests. What do you think? It shouldn't be that different from RID partitions: just partition PK space like RID space is partitionned. I really think the modifications are not that big, unless we find a blocking issue. I will try to think more... Are you sure? I don't think PK space must be partitioned. Protection keys are an additional feature for further access limitations of pages which are already protected via RID. One issue arises with support of protection keys: the hypervisor must be able to run with enabled protection keys as well (protection keys are enabled in %cr.dcr which is not changed in case of interruption). So we will need an own protection key value for the hypervisor and of course a reserved protection key register. For PV domains this should be easy: 15 PKRs should be enough for the DomU. For HVM the PKRs must be virtualized completely. Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Faulty protection key handling
Jürgen Groß wrote: Tristan Gingold wrote: On Wed, Apr 25, 2007 at 03:36:20PM +0200, Dietmar Hahn wrote: Hi, [..] By the way, are there any thoughts about adding emulation of protection keys to the hypervisor? I know, whether the hypervisor nor dom0-linux are using this but we need this stuff. I would try to write a proposal and add using protection keys in the minios for tests. What do you think? It shouldn't be that different from RID partitions: just partition PK space like RID space is partitionned. I really think the modifications are not that big, unless we find a blocking issue. I will try to think more... Are you sure? I don't think PK space must be partitioned. Protection keys are an additional feature for further access limitations of pages which are already protected via RID. One issue arises with support of protection keys: the hypervisor must be able to run with enabled protection keys as well (protection keys are enabled in %cr.dcr which is not changed in case of interruption). So we will need an own protection key value for the hypervisor and of course a reserved protection key register. Sorry, PK is enables in %psr, of course, but there is no corresponding %cr.dcr bit for interrupt defaults. Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Faulty protection key handling
Hi Anthony, Xu, Anthony wrote: By the way, are there any thoughts about adding emulation of protection keys to the hypervisor? I know, whether the hypervisor nor dom0-linux are using this but we need this stuff. I would try to write a proposal and add using protection keys in the minios for tests. What do you think? Hi Dietmar, Frankly, due to there are no OS using protection key, I didn't think about it. While from architecture view, HVM should support protection key. Can you provide more information about why you need to use protection key? While Dietmar is just busy preparing the patches, I'm answering for him :-) We are porting a /390 operating system to ia64/xen. /390 architecture is using a protection key scheme to support memory protection, so using PKRs is the natural design decision to minimize OS impact. There are at least following things we need to do to emulate protection key IMO. 1. Support long format VHPT. protection key is only used by long format VHPT, so we need to support long format VHPT, as I know we already have some logic handling long format VHPT, I think we did fully support long format VHPT now. No, just the other way round. PKR support is necessary for support of long VHPT. You can use PKRs without any VHPT support at all. Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Faulty protection key handling
Psr.pk is unchanged when interrupt happens. So we still need reserve some PK registers for hypervisor. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jürgen Gro? Sent: 2007年4月26日 14:35 Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Faulty protection key handling Jürgen Groß wrote: Tristan Gingold wrote: On Wed, Apr 25, 2007 at 03:36:20PM +0200, Dietmar Hahn wrote: Hi, [..] By the way, are there any thoughts about adding emulation of protection keys to the hypervisor? I know, whether the hypervisor nor dom0-linux are using this but we need this stuff. I would try to write a proposal and add using protection keys in the minios for tests. What do you think? It shouldn't be that different from RID partitions: just partition PK space like RID space is partitionned. I really think the modifications are not that big, unless we find a blocking issue. I will try to think more... Are you sure? I don't think PK space must be partitioned. Protection keys are an additional feature for further access limitations of pages which are already protected via RID. One issue arises with support of protection keys: the hypervisor must be able to run with enabled protection keys as well (protection keys are enabled in %cr.dcr which is not changed in case of interruption). So we will need an own protection key value for the hypervisor and of course a reserved protection key register. Sorry, PK is enables in %psr, of course, but there is no corresponding %cr.dcr bit for interrupt defaults. Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ 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] Faulty protection key handling
From: Jürgen Gro? [mailto:[EMAIL PROTECTED] Sent: 2007年4月26日 14:40 To: Xu, Anthony Cc: Dietmar Hahn; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Faulty protection key handling Hi Anthony, Xu, Anthony wrote: By the way, are there any thoughts about adding emulation of protection keys to the hypervisor? I know, whether the hypervisor nor dom0-linux are using this but we need this stuff. I would try to write a proposal and add using protection keys in the minios for tests. What do you think? Hi Dietmar, Frankly, due to there are no OS using protection key, I didn't think about it. While from architecture view, HVM should support protection key. Can you provide more information about why you need to use protection key? While Dietmar is just busy preparing the patches, I'm answering for him :-) We are porting a /390 operating system to ia64/xen. /390 architecture is using a protection key scheme to support memory protection, so using PKRs is the natural design decision to minimize OS impact. There are at least following things we need to do to emulate protection key IMO. 1. Support long format VHPT. protection key is only used by long format VHPT, so we need to support long format VHPT, as I know we already have some logic handling long format VHPT, I think we did fully support long format VHPT now. No, just the other way round. PKR support is necessary for support of long VHPT. You can use PKRs without any VHPT support at all. Yes, you are right. But for short format VHPT, it is not easy to use PK, due to the protection key is equal to rid by default. It is not flexible. Usually protection key is related with long format VHPT, I remember matt have made a long format VHPT patch for linux.( it is not in the main tree), in this patch, protection key is used to implement TLB entry sharing. Anthony Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Xen-ia64][Patch] optmize some functions
Optmize some functions by changing parameter passing mode from pointer to value. This can reduce redundant memory access. Signed-off-by, Zhang Xin [EMAIL PROTECTED] Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation opt_func.patch Description: opt_func.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Faulty protection key handling
Am Mittwoch, 25. April 2007 schrieb Dietmar Hahn:
Hi,
I played around with the minios and protection key bit in the psr register
and got 3 different behaviors.
1.
mov cr.ipsr = ... (pk bit set)
...
rfi
leads to a hard reboot of the hypervisor. I looked at the rfi emulation and
found, that the pk bit remains untouched. So the protection key stuff is
switched on and the hypervisor and dom0 get some problems.
This seems to be a real critical case. You can test this simply with the
minios by changing line 130 in minios/arch/ia64/ia64.S to
movl r16=STARTUP_PSR | IA64_PSR_PK.
2.
mov r2 = ... (pk bit set)
;;
mov psr.l = r2
Nothing happend. In the source the pk bit is ignored.
3.
ssm psr.pk
leads to a crash of the domU with illegal op which seems to be the right
thing.
I think fixes are needed here for case 1 and 2. If the pk bit is set the
domain should be paniced.
Hi,
attached is a patch, which handles setting psr.pk from domU the same way in
all 3 cases named above. Always the domU is paniced with illegal op.
Thanks.
Dietmar.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID b64739bfc400523479e26458926e6e071a7b96d8
# Parent 9313d0ce09f85e0d883bc5378d1fc9ca7a55a932
Setting of psr.pk bit in the domU leads to a domU panic.
Fixed for emulation of rfi, ssm psr.pk, mov psr.l=reg.
Signed-off-by: Dietmar Hahn [EMAIL PROTECTED]
diff -r 9313d0ce09f8 -r b64739bfc400 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Tue Apr 24 09:26:32 2007 -0600
+++ b/xen/arch/ia64/xen/vcpu.c Thu Apr 26 10:55:00 2007 +0200
@@ -396,6 +396,10 @@ IA64FAULT vcpu_set_psr_l(VCPU * vcpu, u6
//if (val ~(IA64_PSR_PP | IA64_PSR_UP | IA64_PSR_SP))
// return IA64_ILLOP_FAULT;
// however trying to set other bits can't be an error as it is in ssm
+ if (newpsr.pk) {
+ printk(vcpu_set_psr_l: protection keys not supported\n);
+ return IA64_ILLOP_FAULT;
+ }
if (newpsr.dfh) {
ipsr-dfh = 1;
PSCB(vcpu, vpsr_dfh) = 1;
@@ -1356,6 +1360,10 @@ IA64FAULT vcpu_rfi(VCPU * vcpu)
psr.ia64_psr.it = 1;
psr.ia64_psr.bn = 1;
//psr.pk = 1; // checking pkeys shouldn't be a problem but seems broken
+ if(psr.ia64_psr.pk == 1) {
+ printk(vcpu_rfi: protection keys not supported\n);
+ return IA64_ILLOP_FAULT;
+ }
ifs = PSCB(vcpu, ifs);
if (ifs 0x8000UL)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head, or double TLB miss occurs.
Patch: Always insert entry to VHPT head, or TLB miss will occur again although the translation exists in its collision chain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Xiantao Insert entry to VHPT's head.patch Description: Insert entry to VHPT's head.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Faulty protection key handling
On Thu, Apr 26, 2007 at 08:31:11AM +0200, Jürgen Groß wrote: Tristan Gingold wrote: On Wed, Apr 25, 2007 at 03:36:20PM +0200, Dietmar Hahn wrote: Are you sure? I don't think PK space must be partitioned. Protection keys are an additional feature for further access limitations of pages which are already protected via RID. You're right, I spoke too quickly. One issue arises with support of protection keys: the hypervisor must be able to run with enabled protection keys as well (protection keys are enabled in %cr.dcr which is not changed in case of interruption). So we will need an own protection key value for the hypervisor and of course a reserved protection key register. We must also correctly handle metaphysical mode. For PV domains this should be easy: 15 PKRs should be enough for the DomU. For HVM the PKRs must be virtualized completely. I think this is the easiest solution, although it breaks the architecture requirements. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Faulty protection key handling
On Thu, Apr 26, 2007 at 09:08:21PM +0200, Tristan Gingold wrote: On Thu, Apr 26, 2007 at 08:31:11AM +0200, Jürgen Groß wrote: Tristan Gingold wrote: For PV domains this should be easy: 15 PKRs should be enough for the DomU. For HVM the PKRs must be virtualized completely. I think this is the easiest solution, although it breaks the architecture requirements. If you reserve a PKR for the hypervisor, you must reserve a value too. So the PK space must still be reduced ;-) Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Faulty protection key handling
Tristan Gingold wrote: On Thu, Apr 26, 2007 at 09:08:21PM +0200, Tristan Gingold wrote: On Thu, Apr 26, 2007 at 08:31:11AM +0200, Jürgen Groß wrote: Tristan Gingold wrote: For PV domains this should be easy: 15 PKRs should be enough for the DomU. For HVM the PKRs must be virtualized completely. I think this is the easiest solution, although it breaks the architecture requirements. If you reserve a PKR for the hypervisor, you must reserve a value too. So the PK space must still be reduced ;-) For PV this is not completely true. If an OS uses PKRs, it has the same problem as the hypervisor: one PKR with a specific value must always be loaded for interrupt handling. I would see no problem to use the same PKR and PK value as the hypervisor (PKR 0 with PK value 0, rwx allowed). This would eliminate the restriction to 15 PKRs as well. Juergen -- Juergen Gross Principal Developer IP SW OS6 Telephone: +49 (0) 89 636 47950 Fujitsu Siemens Computers e-mail: [EMAIL PROTECTED] Otto-Hahn-Ring 6Internet: www.fujitsu-siemens.com D-81739 Muenchen Company details: www.fujitsu-siemens.com/imprint.html ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
