Hi all,
My name is Tsunehisa Doi.
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg (cs: 10883-10885), it's enabling the hypercall
from HVM domain. Thus, I will post the enabling patch for IPF. This
patch includes:
+ cleanup the hypercall handling code
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
Le Mercredi 02 Aot 2006 12:34, DOI Tsunehisa a crit :
Hi all,
My name is Tsunehisa Doi.
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg (cs: 10883-10885), it's enabling
Hi all,
I modified the code using VMX_DOMAIN macro.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
Le Mercredi 02 Aot 2006 12:34, DOI Tsunehisa a crit :
Hi all,
My name is Tsunehisa Doi.
We are porting
Hi all,
We are porting Steven Smith's para drivers for full-VM to IPF.
In the xen-unstable.hg:
* cs:10911-10912:
+ implement new hypercall called HYPERVISOR_hvm_op.
+ the hypercall has new feature about set/get params.
We want to catch up this common feature. Thus I'll post the
Hi,
Thank you for your comment.
You (Tristan.Gingold) said:
I'd prefer do_hvm_op to be in xen/ and not in vmx/. All the hypercalls are
there.
In x86 code, do_hvm_op is implemented in hvm/hvm.c, thus we have
implemented in vmx/. And we will implement IPF specific feature to
port
Hi,
[EMAIL PROTECTED] wrote:
Sorry!! I refered old version of x86 code. Currently, it modified.
I will correct, soon.
I modified it.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 39feb5061f88cefe00548879459c01e547bc9eec
# Parent
Hi,
You (alex.williamson) said:
On Fri, 2006-08-18 at 21:45 +0900, DOI Tsunehisa wrote:
We want to catch up this common feature. We don't complete to catch
up, yet. But I'll post patches which we wrote already.
This patch includes:
* catch up `hvm_op fixup'
- This patch
Hi all,
I will post patches for catching up the remain features for PV-on-HVM.
* need to catchup for IPF
+ 02.ioemu_xen_evtchns.diff:applied (cs:10974-10976) *not yet*
- Flip the device model over to using the new Xen event channels
+ 04.hvm_inter.diff:applied
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped
Hi,
I'll post a new xen-hyper.patch2, whitch is modified about parameter
checking.
[EMAIL PROTECTED] wrote:
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand
Hi,
You (Tristan.Gingold) said:
I will post patches of PV-on-HVM for IPF.
We wrote the patch under this consideration:
* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original
shared_info page with this
I'll post new xen-hyper.patch3 whitch was modified.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page(pgaddr {
+free_domheap_page(virt_to_page(pgaddr));
+free_xenheap_page((void *)pgaddr);
+
Sorry, I didn't cleanup about indent.
I'll repost new xen-hyper.patch4.
Thanks,
-- Tsunehisa Doi
DOI Tsunehisa wrote:
I'll post new xen-hyper.patch3 whitch was modified.
Thanks,
-- Tsunehisa Doi
[EMAIL PROTECTED] wrote:
+if (likely(IS_XEN_HEAP_FRAME(virt_to_page
Hi all,
Sorry, I have tried to repost it, but my mail tool reformated with format
which I don't want.
I (Doi.Tsunehisa) said:
Tsunehisa Doi wrote:
Hi all,
My name is Tsunehisa Doi.
We have been porting PV-on-HVM feature for ia64 platform.
Sorry, This message is difficult to read.
I (Doi.Tsunehisa) said:
You (Keir.Fraser) said:
On 26/8/06 6:50 am, Tsunehisa Doi [EMAIL PROTECTED] wrote:
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can't implement same feature for IPF, thus we
Hi,
You (alex.williamson) said:
On Sat, 2006-08-26 at 14:45 +0900, $Be.d9(B wrote:
-/* Copy existing grant table shared into new page */
+/* Copy existing grant table new page */
if (o_grant_shared) {
memcpy((void *)d-grant_table-shared,
(void
[EMAIL PROTECTED] wrote:
You (alex.williamson) said:
On Sat, 2006-08-26 at 14:45 +0900, 絎箙 wrote:
-/* Copy existing grant table shared into new page */
+/* Copy existing grant table new page */
if (o_grant_shared) {
memcpy((void *)d-grant_table-shared,
Alex Williamson wrote:
On Mon, 2006-08-28 at 08:35 +0900, [EMAIL PROTECTED] wrote:
In PV-on-HVM driver code, is_running_on_xen and HYPERVISOR_ioremap
have to be used as valid feature. Thus we modified like this.
Doesn't the below do what you need w/o breaking the CONFIG_XEN=n
build?
Hi Anthony,
Thank you for your comment.
You (anthony.xu) said:
I noticed that you use do_yield instead of do_block in xen-event.patch.
I think do_yield will incur some unnecessary schedule before it can resume
to Guest.
Is this comment about vmx_send_assist_req() ?
So, it sets
Hi,
[EMAIL PROTECTED] wrote:
Currently, we are trying to modify PV-on-HVM feature for IPF with
the same method of x86 code. And in preliminary implement, we could do
the feature.
I will post patches for PV-on-HVM on ia64 platform. These patches
modify common code for PV-on-HVM on IPF.
Hi all,
We have been porting PV-on-HVM feature for ia64 platform.
I will post patches for PV-on-HVM on ia64 platform. These patches modify
common code for PV-on-HVM on IPF.
We ported PV-on-HVM for IPF under this consideration:
* Expand memory_op hypercall
+ Introduce
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
I have a question about this modification:
void vcpu_flush_vtlb_all(struct vcpu *v)
{
- /* First VCPU tlb. */
- vcpu_purge_tr_entry(PSCBX(v,dtlb));
- vcpu_purge_tr_entry(PSCBX(v,itlb));
-
- /*
You should add least add a comment because it is unusable to see
VMX_DOMAIN() within paravirtualization area.
OK. I'll append comment to descibe more detail reason.
I'll post new expand-memory-op.patch2.
Thanks,
- Tsunehisa Doi
Expand memory_op for PV-on-HVM on IPF
Signed-off-by:
Hi Alex,
You (alex.williamson) said:
I'll post new expand-memory-op.patch2.
I applied this, but I did have to fix mm.h to make it build. Thanks,
Thank you, and sorry.
I forgot to append mm.h patch with expand-memory-op.patch2.
--
ÅÚÈî¤Ç¤·¤¿¡¥¡¥¡¥
Hi all,
I will post patche for PV-on-HVM on ia64 platform to cleanup for
common code modification minimized.
These patch include:
* cleanup.patch
- ia64_xenmem_reservation_op() and is_running_on_xen() are
macro-nize if CONFIG_VMX_GUEST is defined.
- xen_machphys_update()
Hi,
Thank you for your comment.
Alex Williamson wrote:
On Mon, 2006-09-04 at 16:57 +0900, DOI Tsunehisa wrote:
#include xen/interface/memory.h
+#ifdef CONFIG_VMX_GUEST
+# define ia64_xenmem_reservation_op(op, xmr) (0)
+#else /* CONFIG_VMX_GUEST */
int ia64_xenmem_reservation_op
Hi,
Alex Williamson wrote:
This includes a fairly small number of changesets that I'd like to get
in before 3.0.3. Changes include: finishing the PV-on-HVM driver
support for ia64, fix an error when an FPSWA interface is not installed,
add a few EFI calls to support hwclock, add some more
Hi.
You (yamahata) said:
Your patch isn't SMP-safe.
domVTi code assumes that the p2m table is build at the domain creation and
read-only after that.
However your patch breaks the assumption and opened the door
to SMP world.
Especially you must resolve the race between tlb insert and tlb
Hi Alex,
Please import xen-unstable.hg(cs:11464:3bff5c5b9206) for enabling
PV-on-HVM for IPF.
changeset: 11464:3bff5c5b9206
user:[EMAIL PROTECTED]
date:Wed Sep 13 14:34:34 2006 +0100
summary: Fix unmodified drivers for PV-on-HVM on IA64.
Thanks,
- Tsunehisa
Hi all,
Currently, we are testing PV-on-HVM driver for IPF. so, we found
a problem that hypervisor crashes during VT-i domain destruction
with PV-on-HVM driver.
The procedure to reproduce this problem are:
* Create a VT-i domain.
[dom0]# xm create -f hvm.conf
* Insert modules for
Sorry, I forgot to attach the patch.
DOI Tsunehisa wrote:
Hi all,
Currently, we are testing PV-on-HVM driver for IPF. so, we found
a problem that hypervisor crashes during VT-i domain destruction
with PV-on-HVM driver.
The procedure to reproduce this problem are:
* Create a VT
You (yamahata) said:
On Wed, Sep 27, 2006 at 06:44:27PM +0900, DOI Tsunehisa wrote:
- In x86 code, p2m table invalidation is delayed at last phase of
domain destruction.
= but we don't like it. it seems that p2m table exists after
memory relinquised.
What's
You (yamahata) said:
- In x86 code, p2m table invalidation is delayed at last phase of
domain destruction.
= but we don't like it. it seems that p2m table exists after
memory relinquised.
What's the problem? I don't see why.
In x86 code, it checks ownership of
Hi all,
In x86 code, it was fixed about PV-on-HVM event channel in
xen-unstable.hg(cs:11698).
I fixed with same logic in IPF code.
* bind-evtchn.patch
+ bind event channels of VT-i domain to vcpu 0.
I tested that PV-on-HVM works.
Thanks,
- Tsunehisa Doi
# HG changeset patch
#
Hi Tristan,
You (Tristan.Gingold) said:
Tristan seems to have forgotten to implement xencomm_privcmd_sched_op().
When I tried to reboot a VTI domain, I got the dom0's message
privcmd_hypercall: unknown hcall (29) and couldn't reboot.
Thank you for filling the holes.
I may have forgotten
Hi Tristan,
You (Tristan.Gingold) said:
Do you want me to implement them ?
Yes, I hope to
I've attached the log of compiling PV-on-HVM driver, and
my modification for compiling them.
Hi,
here is my patch. xen_vnif seems to work. Can you try and confirm ?
Have you ever
on it?
Sorry, I could not spend to investigate this issue in last few
weeks. Could you help me ?
Thanks,
- Doi Tsunehisa
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
You (yamahata) said:
Although I haven't dug into its details, I want to check my suspicion.
The relinquishing mm code assumes that there's no racy reference.
So your patch seems too easy and not-SMP-safe to me.
For example, mm-pgd isn't protected.
What do you think?
You are right.
You (yamahata) said:
It might take a while for you to fix it.
Can you add comments to mark them until fix? e.g. XXX not-SMP-safe.
Sorry. I can't spend for the issue, now.
Could you add them ?
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing
Hi all,
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
- add not-SMP-safe comment
Hi all,
I (Doi.Tsunehisa) said:
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I attach several patches about PV-on-HVM.
+ fix-warning.patch
- warning fix for HVM PV driver
+ notsafe-comment.patch
Sorry, I forgot to write about my test environment.
I tested with xen-ia64-unstable.hg (cs:11810).
I (Doi.Tsunehisa) said:
Hi all,
I (Doi.Tsunehisa) said:
We've ported PV-on-HVM drivers for IPF. But I think that
only few tries it. Thus, I try to describe to use it.
And I
Hi Tristan,
Thank you for your comment.
You (Tristan.Gingold) said:
[linux-2.6.16.29 on VT-i domain]
# cat /proc/iomem
-0009 : System RAM
000a-000b : reserved
000c-000f : reserved
0010-03ff : System RAM
0400-04bf3fff : System RAM
Hi,
You (yamahata) said:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
I
Hi Alex,
Alex Williamson wrote:
I think the issue is same as reported in the below thread.
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-09/msg00204.html
I tried to convince him, but failed.
I think that the best way is to revert the patch and we should seek
for the right fix.
at: xenwatch_thread+0x1e0/0x3a0 [xenbus]
Best Regards,
Yongkang (Kangkang) [EMAIL PROTECTED](B
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DOI
Tsunehisa
Sent: 2006$BDj(B10$BTB(B16$BHU(B 20:31
To: xen-ia64-devel
Subject
You (yongkang.you) said:
Does it output this trace back message when you detach vnif with
xm network-detach command ?
No. I didn't use above command to detach vnif. Usually I used following
ways to enable vnif NIC.
1. create VTI with vif = [ '' ]
2. After VTI boot up, insert 3 related PV
You (Tristan.Gingold) said:
On RHEL4 U2 kernel (Linux version 2.6.9-22.EL), xen-platform-pci
includes `PCI Bus :00', but it should be the leaf node, I think.
To insmod xen-platform-pci, this iomem space was conflicted with
the inner device, thus it can't be attached.
At least RHEL4 U2
Hi Alex,
Alex Williamson wrote:
Ok, should I simply revert xen-ia64-unstable cset 11636:3470d9cd27e5?
Basically, yes. But we can't avoid hypervisor crash during domain
destruction.
I think to modify above patch to remove VT-i domain checker like
attaced patch, until we will success
Hi Tristan,
Thank you for many advices and suggestion. I've been fortunate
to have good time to work with you.
You (Tristan.Gingold) said:
Hi,
before leaving Bull I'd like to thanks everyone.
Thanks to HP for initiating Xen/ia64 and managing the project in a very
democratic way.
Hi Ian,
You (Ian.Campbell) said:
I'd much prefer it if we can find a way to avoid encoding specific RHEL
kernel versions as you had in your patch. I've gone with
#define gfp_t unsigned
which basically ignores any existing typedef. I think this is OK in this
instance since gfp_t has
You (yamahata) said:
Some comments.
- Probably IA64 specific code paths assume that if the p2m conversion
gives valid mfn, then the page isn't free.
Your patch breaks it. I haven't check it though.
In our investigation, the domain is paused at domain_kill phase, thus
it don't occur the
Hi,
You (yamahata) said:
- Probably IA64 specific code paths assume that if the p2m conversion
gives valid mfn, then the page isn't free.
Your patch breaks it. I haven't check it though.
In our investigation, the domain is paused at domain_kill phase, thus
it don't occur the issue,
You (yamahata) said:
I think, the p2m table of the domain (during destruction indeed)
is not modified by any domain. Gran table reference has a possiblity
of p2m table modified by other domain, but in this case, grant table
reference releases before `shadow_teardown'.
Grant table page
You (yamahata) said:
Hmm, I've thought that gnttab_release_mapping() ensures it...
No. gnttab_release_mapping() is for a domain which maps a page granted by
another domain. Not for a domain which grants page mapping.
Ok. I understood it.
However during shadow_teardown_xxx() in your
Thank you for your suggestion.
We'll study it.
Thanks,
- Tsunehisa Doi
You (yamahata) said:
However during shadow_teardown_xxx() in your patch
other domain might access the p2m table and struct page_info.
Page reference convension must be kept right during them.
Yes, it might
Hi,
It's a temporary solution to avoid hypervisor crash...
We can avoid to crash hypervisor with `xm network-detach' command.
Before the domain destruction, you should detach all VNIF of the domain
with `xm network-detach domid nifid' command, if you want to avoid
crash hypervisor.
Thanks,
Hi Anthony,
You (anthony.xu) said:
Due to we are using pci irq(15) for platform_pci,
We may need to revert back this patch(Issue about interrupt for PV-on-HVM
on IPF).
Sorry, please tell me about the change.
Actually, what will GSI for platform_pci become ?
Thanks,
- Tsunehisa Doi
Due to we are using pci irq(15) for platform_pci,
We may need to revert back this patch(Issue about interrupt for
PV-on-HVM on IPF).
Sorry, please tell me about the change.
Actually, what will GSI for platform_pci become ?
It becomes 28.
$B!!(BThanks...
Hmm.. I'll have to
You (anthony.xu) said:
[EMAIL PROTECTED] write on 2006$BG/(B12$B7n(B1$BF|(B 17:53:
Due to we are using pci irq(15) for platform_pci,
We may need to revert back this patch(Issue about interrupt for
PV-on-HVM on IPF).
Sorry, please tell me about the change.
Actually, what
Hi,
I (Doi.Tsunehisa) said:
Hmm.. Current implement needs the GSI for platform-pci to follow
status of virtual IOSAPIC in hypervisor side. But, it's not certain
value from virtual IOSAPIC at calling set_callback_irq hypercall.
I'll be thinking more...
I've investigated it, but I
Hi Anthony,
You (anthony.xu) said:
* Hypervisor becomes to be able to use both GSI and Vector for
callback irq.
- For example, if it is normal value, HV accepts it as GSI.
If it is value which is set MSB, HV accepts it as Vector.
* If hypervisor gets Vector as callback irq,
Hi Anthony,
Thank you for your comment.
You (anthony.xu) said:
Hardware IRQ is equal to GSI, but the IRQ in IPF-linux world is
abstruct value not GSI. So we need to get GSI for platform-pci from
IPF-linux world's IRQ. But I didn't find it.
* Hypervisor becomes to be able to use both
Hi Anthony,
You (anthony.xu) said:
We had implemented older PV-on-HVM with the method like this.
But, we found the issue that interrupt was injected during interrupt
masking of VIOSAPIC. So we changed to implement it.
In this time, we have to implement it that interrupt injection
You (anthony.xu) said:
BTW, in my experience, the vector doesn't set to VIOSAPIC at
HVMOP_set_param hypercall. Thus I'll implement to find the GSI at
interrupt injection phase.
In this case,
Can we call set_callback_irq with hardware irq inside Qemu rather than
platform_pci, just after
Hi Anthony,
You (anthony.xu) said:
Sorry, I don't know this issue for detail. I think that the guest
OS sets interrupt mask register of VIOSAPIC until setting own vector.
I assume that the guest OS might change the vector for such hardware
in active state.
Hi Doi,
This issue is from
Hi Anthony,
This issue is from you, guest linux uses vector, while there is no
function like vector_to_irq.
Sorry, I might misunderstand your comment.
I've been thinking more about your comment.
We may be able to call set_callback_irq inside qemu, but I don't
think that it's good
Hi Anthony,
You (anthony.xu) said:
Do you meen that we have to modify qemu code to solve this isssue ?
Doi,
I think it's a clean way to handle both windows and linux guest in IPF side.
And it is a very little modification in Qemu.
But maybe IA32 can not use this method, because there
Hi all,
I modified to follow new interrupt deliver mechanism for PV-on-HVM/IPF.
New interrupt deliver mechanism changed GSI of pseudo hardware for
PV-on-HVM. So, old get_callback_irq function can't get GSI of it.
In this case, I modified that PV-driver notices Requester-ID(RID) to
hypervisor
Hi Alex,
Thank you for your comment.
You (alex.williamson) said:
+return rid | (1 31); /* with RID marker(MSB) */
Ok, except (1 31) needs to be defined in a common header somewhere
so it's not just a random magic bit. Thanks,
I agree it.
I think that the definition should
You (alex.williamson) said:
I think that the definition should be in xen/include/public/hvm/params.h
or xen/include/public/arch-ia64.h.
What do you think about this ?
It's ia64 specific, so arch-ia64.h seems more appropriate.
Thank you for your advice. I'll modify the code with
Hi Alex,
[EMAIL PROTECTED] wrote:
You (alex.williamson) said:
I think that the definition should be in xen/include/public/hvm/params.h
or xen/include/public/arch-ia64.h.
What do you think about this ?
It's ia64 specific, so arch-ia64.h seems more appropriate.
Thank you for your
You (anthony.xu) said:
Hi Doi-san
I know you are working on PV-ON-HVM,
Applying both attatchments can make VBD work on VTI-domain on Cset 13465,
I didn't try VNIF. In case we are doing the duplicated thing.
Hi Anthony-san,
Thank you!! I'll try it.
BTW, in x86 code, the spec of
Hi Anthony-san,
Thank you for your information.
We'll try with latest changeset (cs:13837).
You (anthony.xu) said:
Hi Doi-san,
I think you should try Cs13774 or latest Cset,
The patch of Optimize hypercall path in VTI domain was checked in at Cs
13774.
And this patch is a must for
Hi Anthony-san,
I've checked it latest changeset (cs:13837). VNIF is available
with the patch.
I'll submit the patch and following patch.
Thanks,
- Tsunehisa Doi
I (Doi.Tsunehisa) said:
Hi Anthony-san,
Thank you for your information.
We'll try with latest changeset
Hi all,
I modified to fix for compiling PV-on-HVM driver on IPF, and follow
to allow PV-on-HVM callback irq to be identified by PCI device.
In x86 code, callback irq spec was appended few weeks ago. The purpose
of appended spec was same with that we had introduced using RID for
callback irq.
Hi Alex,
You (alex.williamson) said:
--- a/xen/include/public/arch-ia64.hMon Feb 05 13:19:10 2007 +0900
+++ b/xen/include/public/arch-ia64.hMon Feb 05 13:20:48 2007 +0900
@@ -64,9 +64,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
#define VIRQ_MCA_CMCVIRQ_ARCH_1 /* MCA cmc interrupt
Hi Alex,
Alex Williamson wrote:
IMHO, if it's #if 0'd out, it's not really adding to backwards
compatibility anyway. This wasn't in 3.0.4, so I think we should
probably drop it. Thanks,
I agree. I've modified the patch.
Thanks,
- Tsunehisa Doi
# HG changeset patch
# User [EMAIL
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DOI
Tsunehisa
Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34
To: xen-ia64-devel
Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Hi all,
In the latest ia64-unstable tree, we can't build PV-on-HVM
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DOI
Tsunehisa
Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34
To: xen-ia64-devel
Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Hi all,
In the latest ia64-unstable tree, we can't build
Hi all,
In last week, I submitted the patch to fix for compiling PV-on-HVM.
But, it crashed hypervisor, so..
I (Doi.Tsunehisa) said:
We'll have to modify the arch_memory_op code to follow dynamic grant
table size feature in the hypervisor side.
I've be investigating this issue, thus I
Hi Yamahata-san,
Thank you for your comment.
You (yamahata) said:
On Tue, Mar 06, 2007 at 09:56:14PM +0900, DOI Tsunehisa wrote:
- we have to modify guest_physmap_add_page() to support it.
(this is straight reason of hypervisor crash)
The patch breaks the the p2m/m2p table
You (yamahata) said:
Currently, without this patch, hypervisor crashes in PV-on-HVM
initialization phase..
* at share_info page remapping: success
- called from HYPERVISOR_memory_op in init_xen_info()..
(unmodified_drivers/linux-2.6/platform-pci/platform-pci.c)
* at grant
Hi Yamahata-san,
I (Doi.Tsunehisa) said:
And, I've tracked the counter, so it be cleared below:
[xen/arch/ia64/xen/mm.c]
long
arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
{
/* Unmap from old location, if any. */
gpfn = get_gpfn_from_mfn(mfn);
Subject: Re: [Patch] Fix for re-enabling PV-on-HVM on IPF
Hi all,
I've modified the paches according to Yamahata-san's suggestion.
* pvfix.patch
- fix for compling PV-on-HVM driver on IPF.
- this is same as that I send in last week.
* hcall-rval.patch
- fix about a return
Hi Yamahata-san,
Thank you for your comment.
You (yamahata) said:
On Thu, Mar 08, 2007 at 01:06:04PM +0900, DOI Tsunehisa wrote:
diff -r 61eb6589e720 -r b602dd142385 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Mar 06 21:11:37 2007 +0900
+++ b/xen/arch/ia64/xen/mm.c
You (yamahata) said:
+
guest_physmap_remove_page(d, gpfn, mfn);
+
+/* post-set PGC_allocated flag */
+do {
+x = mfn_to_page(mfn)-count_info;
+if ((x PGC_count_mask) == 0)
+goto out;
+
You (yamahata) said:
Probably it should looks like the following.
if (page-count_info != 1) { /* no one but us is using this page */
put_page(page);
goto out;
}
__set_bit(page-count_info, _PGC_allocated);
Does `page-count_info' have to be operated with atomic ?
Atomic
Hi all,
I've modified it, so submit the patch.
[EMAIL PROTECTED] wrote:
You (yamahata) said:
Probably it should looks like the following.
if (page-count_info != 1) { /* no one but us is using this page */
put_page(page);
goto out;
}
__set_bit(page-count_info, _PGC_allocated);
Hi Isaku,
Sorry for late response.
You (yamahata) said:
Tsunehisa.
I haven't tested arch_memory_op(). Could you verify it?
I've checked this patch on the latest change set(cs:14513).
It occured hypervisor crash at that xen-platform.ko was inserted.
And, hypervisor said as follow:
FYI.
Original change set is not crashed.
I (Doi.Tsunehisa) said:
Hi Isaku,
Sorry for late response.
You (yamahata) said:
Tsunehisa.
I haven't tested arch_memory_op(). Could you verify it?
I've checked this patch on the latest change set(cs:14513).
It occured hypervisor
Hi Isaku,
I (Doi.Tsunehisa) said:
If so, the BUG_ON() is bogus. Probably it should be something like
BUG_ON(page-count_info != 1 page-count_info != (PGC_allocated | 1)).
BUG_ON((page-count_info PGC_count_mask) != 1) is better, I think.
I've checked this modification. PV-on-HVM driver
You (yamahata) said:
Thanks. Attached updated one.
I've tested this patch. PV-on-HVM driver worked correctly.
Thanks,
- Tsunehisa Doi
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
93 matches
Mail list logo
