[Xen-ia64-devel][PATCH] eliminate redundant wakeup logic
This wakeup is redundant Signed-off-by, Anthony Xu [EMAIL PROTECTED] deliver_interrupt.patch Description: deliver_interrupt.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Support big endian domU's
Hi,
I started with supporting big endian domU's on ia64 and have some questions.
I did some changes to tools/libxc/xc_load_elf.c and now I can load and start
the big endian domU.
Because this is some sort of a new branch in load_elf how can I get in
changes? Should I simply send patches to x86 list or should I first initiate
a discussion about that?
I added a flag is_be to struct arch_domain. Is this ok, or may this produce
some problems?
struct arch_domain {
struct mm_struct mm;
/* Flags. */
union {
unsigned long flags;
struct {
unsigned int is_vti : 1;
#ifdef CONFIG_XEN_IA64_PERVCPU_VHPT
unsigned int has_pervcpu_vhpt : 1;
#endif
unsigned int is_be : 1;
};
};
Should I introduce a new compiler flag where the special big endion support
can be switched off?
A question to the function reflect_interruptions() in fault.c:
As far as I understand the code, PSCB(...) are prepared to contain the trapped
dumU environment..
regs-... are prepared to contain the environment for return to the trap
handler of the domU.
If this is the case then on a big endian domU the psr.be bit ist not set in
regs-ipsr from dcr.be. This is needed on return from Xen to the trap handler
of the domU.
The other thing is that in vcpu_get_ipsr_int_state() the psr.be bit should not
be overwritten by dcr.be. There are cases where a big endian domU runs
temporarily littlen endian (during efi calls, ...). If there would be a trap,
it would return with psr.be = 1, which is not what we want.
The same problem may occur on reflect_event()!
Thanks.
Dietmar.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Support big endian domU's
Hi, Dietmar
I started with supporting big endian domU's on ia64 and have some questions.
I did some changes to tools/libxc/xc_load_elf.c and now I can load and start
the big endian domU.
Because this is some sort of a new branch in load_elf how can I get in
changes? Should I simply send patches to x86 list or should I first initiate
a discussion about that?
Is the changes related to x86?
If so, we should discuss on xen-devel.
I added a flag is_be to struct arch_domain. Is this ok, or may this produce
some problems?
struct arch_domain {
struct mm_struct mm;
/* Flags. */
union {
unsigned long flags;
struct {
unsigned int is_vti : 1;
#ifdef CONFIG_XEN_IA64_PERVCPU_VHPT
unsigned int has_pervcpu_vhpt : 1;
#endif
unsigned int is_be : 1;
};
};
I feel like this is ok, but you may add __attribute__((aligned(8))).
Should I introduce a new compiler flag where the special big endion support
can be switched off?
Yes,I think so.
Isaku often introduce new flags, I like the way. :)
A question to the function reflect_interruptions() in fault.c:
As far as I understand the code, PSCB(...) are prepared to contain the
trapped
dumU environment..
regs-... are prepared to contain the environment for return to the trap
handler of the domU.
If this is the case then on a big endian domU the psr.be bit ist not set in
regs-ipsr from dcr.be. This is needed on return from Xen to the trap handler
of the domU.
The other thing is that in vcpu_get_ipsr_int_state() the psr.be bit should
not
be overwritten by dcr.be. There are cases where a big endian domU runs
temporarily littlen endian (during efi calls, ...). If there would be a trap,
it would return with psr.be = 1, which is not what we want.
The same problem may occur on reflect_event()!
I don't understand this issue very much.
But can you check is_be flags, and restore psr.be in each cases?
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Support big endian domU's
On Thu, Nov 16, 2006 at 01:11:18PM +0100, Dietmar Hahn wrote:
I started with supporting big endian domU's on ia64 and have some questions.
I did some changes to tools/libxc/xc_load_elf.c and now I can load and start
the big endian domU.
Because this is some sort of a new branch in load_elf how can I get in
changes? Should I simply send patches to x86 list or should I first initiate
a discussion about that?
If you have already (even imcomplete) patches, it would be good
to initiate a discussion with the patch sending a mail of the
subject [RFC][PATCH] on x86 list.
I added a flag is_be to struct arch_domain. Is this ok, or may this produce
some problems?
Although I'm not sure how the flag is used, I don't suppose that
it would cause issues to introduce the new flag.
I think that big endianess is per-vcpu issue, not per-domain,
so that I don't think is_be is necessary. Could you elaborate on is_be?
struct arch_domain {
struct mm_struct mm;
/* Flags. */
union {
unsigned long flags;
struct {
unsigned int is_vti : 1;
#ifdef CONFIG_XEN_IA64_PERVCPU_VHPT
unsigned int has_pervcpu_vhpt : 1;
#endif
unsigned int is_be : 1;
};
};
Should I introduce a new compiler flag where the special big endion support
can be switched off?
A question to the function reflect_interruptions() in fault.c:
As far as I understand the code, PSCB(...) are prepared to contain the
trapped
dumU environment..
regs-... are prepared to contain the environment for return to the trap
handler of the domU.
If this is the case then on a big endian domU the psr.be bit ist not set in
regs-ipsr from dcr.be. This is needed on return from Xen to the trap handler
of the domU.
The other thing is that in vcpu_get_ipsr_int_state() the psr.be bit should
not
be overwritten by dcr.be. There are cases where a big endian domU runs
temporarily littlen endian (during efi calls, ...). If there would be a trap,
it would return with psr.be = 1, which is not what we want.
The same problem may occur on reflect_event()!
Thanks.
Dietmar.
___
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
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#12464
Xen/IA64 Healthiness Report Several issues are still in this changeset: 1. VTI Linux domain boot slowly, if enabled 'serial=pty' 2. VTI Windows almost can not boot up with 'serial=pty' 3. Destroying 2 SMP XenU domains might meet Xen0 Crashing. 4. XenU might stop to boot when creating with another VTI domain together. 5. VTI domain rebooting failure. Except above issues, all nightly cases can pass in automated and manually testing. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.15 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 12464:ac5330d4945a Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.11.07 MD5: 797c2d6c391a6fc6f16d267e01b382f8 Summary Test Report: - Total cases: 16 Passed:16 Failed: 0 Case Name Status Case Description Four_SMPVTI_Coexistpass 4 VTI (mem=256, vcpus=2) Two_UP_VTI_Co pass 2 UP_VTI (mem=256) One_UP_VTIpass1 UP_VTI (mem=256) One_UP_XenU pass1 UP_xenU(mem=256) SMPVTI_LTPpassVTI (vcpus=4, mem=512) run LTP SMPVTI_and_SMPXenU pass 1 VTI + 1 xenU (mem=256 vcpus=2) Two_SMPXenU_Coexistpass 2 xenU (mem=256, vcpus=2) One_SMPVTI_4096M pass 1 VTI (vcpus=2, mem=4096M) SMPVTI_Network pass 1 VTI (mem=256,vcpu=2) and 'ping' SMPXenU_Networkpass 1 XenU (vcpus=2) and 'ping' One_SMP_XenU pass 1 SMP xenU (vcpus=2) One_SMP_VTIpass 1 SMP VTI (vcpus=2) SMPVTI_Kernel_Build pass VTI (vcpus=4) and do Kernel Build Four_SMPVTI_Coexist pass 4 VTI domains( mem=256, vcpu=2) SMPVTI_Windows pass SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU passSMPVTI Linux/Windows XenU UPVTI_Kernel_Build pass 1 UP VTI and do kernel build Notes: - The last stable changeset: - 12004:cf05aabe6e65 Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] VTI Windows installation and booting HowTo
Hi all, VTI Windows 2003 has brought up in IA64 platform for a long time. Recently, by community and Intel's several important bugs fixing, SMP VTI Windows (8vcpus) could pass HCT stress testing for 24 hours. Here, I provide some steps for VTI Windows 2k3 installation and booting. Environment: Platform: Tiger4 Processor: Itanium 2 Processor with VT supported. Logic Processors number: 16 (4 processors with Due Core + HT) PAL version: 8.15 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: Windows 2k3 Xen IA64 Unstable tree: 12014:9c649ca5c1cc Xen Schedule: credit VTI Guest Firmware Flash.fd.2006.11.07 MD5: 797c2d6c391a6fc6f16d267e01b382f8 Installation: -- Windows Server 2003 SP1 installation in VTI: 1. Prepare a physical disk or a disk image file. ( This know-how uses /dev/sdc physical disk to install Windows ) Modify 'disk' and 'boot' line in /etc/xen/xmexample.vti as disk = [ 'phy:/dev/sdc,hda,w', \ 'file:/var/images/winsvr2003sp1.ISO,hdc:cdrom,r' ] #if using disk image: #disk = [ 'file:/var/images/winXP.img,hda,w', \ 'phy:/dev/cdrom,hdc:cdrom,r' ] boot='d' = 2. xm create /etc/xen/xmexample.vti Once in the VTi Domain In EFI shell, go into CDROM. It can be either fs0: or fs1: fs0: Run setupldr.efi to start installation. (use quickest installation) : setupldr.efi After Windows installation copying files, it will do the 1st reboot. (In recent Changeset, there is a bug will cause VTI domain reboot failed. If it automatically reboot fail, could manually create VTI again.) 3. In EFI shell, go to fs0: ; run cp efi\microsoft\winnt50\boot . 4. Go to msutil\ ; run nvrboot; input I - boot - ENTER - Q; exit EFI shell; continue. 5. Windows will the perform installation. It takes 5 hours to complete installation. VTI domain still met slow CD-ROM issue, which will cause VTI domain installation slowly. In recent Changeset VTI performance depredates a lot, the installation might be slower. 6. After installation, follow step #4, you can boot VTI Windows 2003 SP1. 7. With guest firmware Flash.fd.2006.11.07, VTI Windows can be automatically boot without step #4 by adding a file startup.nsh in its 1st vfat partition (fs0:\startup.nsh). == #mount /dev/sdc1 /mnt/sdc1 #cat /mnt/sdc1/startup.nsh EOF bcfg boot addf 1 fs0:\boot windows EOF #umount /mnt/sdc1 == Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [IA64] fix xencomm_handle_is_null().
On Thu, 2006-11-16 at 09:55 -0600, Hollis Blanchard wrote: I think I'm missing something. Why did IA64 fork xencomm? I distinctly remember having conversations about sharing the code, which is obviously the right thing to do. Because Tristan believed the resulting amount of shared code would actually be very small (1 file) and we wanted to get his work into the tree before he left Bull. We can still work to share as much as possible even with the code split. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-users] ia64 questions/problems
Hi David, At times, xen-unstable tree is broken for IA64 due to sync problems, you'd better use xen-ia64-unstable tree. For further help and discussion, you should definitely come to ia64- xen-devel mailing list. Thanks, Yoshi Oguchi -- David Brown [EMAIL PROTECTED] wrote: I've been messing around with xen on ia64, found several of the wiki pages and lots of information. I've been using the http://xenbits.xensource.com/xen-unstable.hg since one of the pages said that's the code that has the most support for ia64. However, I've had some issues compiling the source the past few days and have some questions. 1. Which mailing list should I use for compilation issues? and where should I submit patches? 2. Is there any specific groups I should pay attention to for new ia64 support issues? 3. What kind of testing would be most useful for you guys when it comes to ia64? - David Brown ___ Xen-users mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-users ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-users] XEN-IA64 availability?
Hi Jhelum, Could anyone please tell me that the Xen-IA64 is available. Does for Xen-IA64 any different chipset or h/w requirement is there or its installation is same as that of xen-x86? Xen for ia64 is available and working fine. If you want to run HVM domains you need the latest Itanium2 (Montecito) , otherwise any Itanium2 should be OK. For a starter, you can look up xen-wiki page , http://wiki.xensource.com/xenwiki/HelpOnInstalling/XenOnia64 or, you can always ask xen-ia64-devel mailing list for further help. Thanks, Yoshi Oguchi -- Jhelum Bisht [EMAIL PROTECTED] wrote: hi, Could anyone please tell me that the Xen-IA64 is available. Does for Xen-IA64 any different chipset or h/w requirement is there or its installation is same as that of xen-x86? Regards, Jhelum - Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
