[kvm-ppc-devel] Current e500 kvm guest kernel booting log

[kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

Hi,

Thanks Hollis' 'hack' codes!
I've ported them to e500 core and booted something from e500 core kvm of
PowerPC. Because of no qemu to emulate IO, the guest kernel halts before
CPU's peripheral equipment (such as mpic) operations. The log is output
from the serial port.

Log:
Memory <- <0x0 0x8000000> (-1408896MB)
CPU clock-frequency <- 0x4ead9a00 (1320MHz)
CPU timebase-frequency <- 0x3ef1480 (66MHz)
CPU bus-frequency <- 0x1f78a400 (528MHz)

zImage starting: loaded at 0x00400000 (sp: 0x00fffeb8)
Allocating 0x2ca080 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x006d0314)...done 0x2b0124 bytes

Linux/PowerPC load: root=/dev/nfs rw
nfsroot\x192.168.1.10:/tftpboot/192.168.1.16
ip\x192.168.1.16:192.168.1.10:192.168.1.1:255.255.255.0:unknown:eth0:off
console=ttyS1,115200
Finalizing device tree... flat tree at 0x40a8d0
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0dMb, CAM1dMb, CAM2=0Mb residual: 0Mb
Linux version 2.6.24-rc1-ga3c0a29d-dirty (zhangwei@bus) (gcc version
4.1.2) #336 Mon Dec 10 13:21:15 CST 2007
 -> find_legacy_serial_port()
stdout is /soc8568@e0000000/serial@4600
legacy_serial_console = 1
default console speed = 115200
 <- find_legacy_serial_port()
console [udbg0] enabled
setup_arch: bootmem
mpc85xx_mds_setup_arch()
arch: exit
Zone PFN ranges:
  DMA             0 ->    32768
  Normal      32768 ->    32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
32512
Kernel command line: root=/dev/nfs rw
nfsroot\x192.168.1.10:/tftpboot/192.168.1.16
ip\x192.168.1.16:192.168.1.10:192.168.1.1:255.255.255.0:unknown:eth0:off
console=ttyS1,115200

The memory initialization is finished.

Cheers!
Wei

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Hollis Blanchard]

Congratulations! :) Will you send patches? What are your thoughts on the
commonality between 440 and e500 code?

We haven't touched the "hack" code recently, since we've been
refactoring the upstream tree. That's pretty much done though, and right
now I'm just starting to integrate the old 440 support with the new
upstream code. That's not in a good state right now, but I could clean
it up and send it out if you're interested.

Also, I'm messing around with Makefiles now, and have been thinking
about how to connect the modules... For example, should there be a
kvm-powerpc-guest-440.ko that could link with kvm-powerpc-host-e500.ko?
For now, a single kvm-powerpc-e500.ko (e500 guests on e500 host) is
probably easiest, but we should think about the long-term goal too.

By the way, we booted with an initrd so we wouldn't need the network,
and hacked the device tree not to use interrupts for the UART. If you
take shortcuts like that you can really minimize your dependency on qemu
for now.

-- 
Hollis Blanchard
IBM Linux Technology Center

On Tue, 2007-12-11 at 13:01 +0800, Zhang Wei wrote:
> Hi,
> 
> Thanks Hollis' 'hack' codes!
> I've ported them to e500 core and booted something from e500 core kvm of
> PowerPC. Because of no qemu to emulate IO, the guest kernel halts before
> CPU's peripheral equipment (such as mpic) operations. The log is output
> from the serial port.
> 
> Log:
> Memory <- <0x0 0x8000000> (-1408896MB)
> CPU clock-frequency <- 0x4ead9a00 (1320MHz)
> CPU timebase-frequency <- 0x3ef1480 (66MHz)
> CPU bus-frequency <- 0x1f78a400 (528MHz)
> 
> zImage starting: loaded at 0x00400000 (sp: 0x00fffeb8)
> Allocating 0x2ca080 bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040d000:0x006d0314)...done 0x2b0124 bytes
> 
> Linux/PowerPC load: root=/dev/nfs rw
> nfsroot\x192.168.1.10:/tftpboot/192.168.1.16
> ip\x192.168.1.16:192.168.1.10:192.168.1.1:255.255.255.0:unknown:eth0:off
> console=ttyS1,115200
> Finalizing device tree... flat tree at 0x40a8d0
> Using MPC85xx MDS machine description
> Memory CAM mapping: CAM0dMb, CAM1dMb, CAM2=0Mb residual: 0Mb
> Linux version 2.6.24-rc1-ga3c0a29d-dirty (zhangwei@bus) (gcc version
> 4.1.2) #336 Mon Dec 10 13:21:15 CST 2007
>  -> find_legacy_serial_port()
> stdout is /soc8568@e0000000/serial@4600
> legacy_serial_console = 1
> default console speed = 115200
>  <- find_legacy_serial_port()
> console [udbg0] enabled
> setup_arch: bootmem
> mpc85xx_mds_setup_arch()
> arch: exit
> Zone PFN ranges:
>   DMA             0 ->    32768
>   Normal      32768 ->    32768
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0:        0 ->    32768
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> 32512
> Kernel command line: root=/dev/nfs rw
> nfsroot\x192.168.1.10:/tftpboot/192.168.1.16
> ip\x192.168.1.16:192.168.1.10:192.168.1.1:255.255.255.0:unknown:eth0:off
> console=ttyS1,115200
> 
> The memory initialization is finished.
> 
> Cheers!
> Wei
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> kvm-ppc-devel mailing list
> kvm-ppc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

> 
> Congratulations! :) Will you send patches? What are your 
> thoughts on the
> commonality between 440 and e500 code?

Thanks! The MMU and some core registers are different, but almost of the
other can be reused. So I change 440 TLB functions to core independence
API and add an exceptions_e500.S file.

> 
> We haven't touched the "hack" code recently, since we've been
> refactoring the upstream tree. That's pretty much done 
> though, and right
> now I'm just starting to integrate the old 440 support with the new
> upstream code. That's not in a good state right now, but I could clean
> it up and send it out if you're interested.

Yes! I think hack codes are only for verifying the idea. Our target is
for
upstream code. I hope I could join you!

> 
> Also, I'm messing around with Makefiles now, and have been thinking
> about how to connect the modules... For example, should there be a
> kvm-powerpc-guest-440.ko that could link with 
> kvm-powerpc-host-e500.ko?
> For now, a single kvm-powerpc-e500.ko (e500 guests on e500 host) is
> probably easiest, but we should think about the long-term goal too.
> 

I will make some studies about this. What's kvm-guest-xxx.ko and
kvm-host-xxx.ko?
Why not one kvm-powerpc.ko?

> By the way, we booted with an initrd so we wouldn't need the network,
> and hacked the device tree not to use interrupts for the UART. If you
> take shortcuts like that you can really minimize your 
> dependency on qemu
> for now.
> 

How about the qemu position in our roadmap? If it still be the key role,
I'll have to add some e500 hw drivers into it.

Cheers!
Wei.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Hollis Blanchard]

On Wed, 2007-12-12 at 19:57 +0800, Zhang Wei wrote:
> > 
> > Congratulations! :) Will you send patches? What are your 
> > thoughts on the
> > commonality between 440 and e500 code?
> 
> Thanks! The MMU and some core registers are different, but almost of the
> other can be reused. So I change 440 TLB functions to core independence
> API and add an exceptions_e500.S file.

Interesting, good to know.
 
> > We haven't touched the "hack" code recently, since we've been
> > refactoring the upstream tree. That's pretty much done 
> > though, and right
> > now I'm just starting to integrate the old 440 support with the new
> > upstream code. That's not in a good state right now, but I could clean
> > it up and send it out if you're interested.
> 
> Yes! I think hack codes are only for verifying the idea. Our target is
> for upstream code. I hope I could join you!

Well, unfortunately at the moment I'm just fighting with
asm-offsets.h . :( Since I'm basically already on vacation, I'm not sure
I'll be able to get anything ready until January.

> > Also, I'm messing around with Makefiles now, and have been thinking
> > about how to connect the modules... For example, should there be a
> > kvm-powerpc-guest-440.ko that could link with 
> > kvm-powerpc-host-e500.ko?
> > For now, a single kvm-powerpc-e500.ko (e500 guests on e500 host) is
> > probably easiest, but we should think about the long-term goal too.
> > 
> 
> I will make some studies about this. What's kvm-guest-xxx.ko and
> kvm-host-xxx.ko?
> Why not one kvm-powerpc.ko?

Books 1 and 2 are (more or less) identical across PowerPC. Book 3 is
where the big differences are, but we are emulating all Book 3 stuff in
software. That means we can emulate whatever Book 3 we want; we don't
need to run only e500 guests on e500 hosts.

So, we could in theory have a module that e.g. emulates the e500 Book 3,
which we'd call something like kvm-powerpc-e500-guest.ko. If we emulate
tlbwe with HTAB modifications, we could run e500 guests on an e600. We
would call the module with the HTAB logic something like
kvm-powerpc-e600-host.ko.

The important point for the MMU is that all PPC have the concept of a
virtual address, which is an effective address + some context
identifier. On classic or server PPC, that context comes from
segmentation (SRs, SLB, or STAB), whereas on Book E the context is AS +
PID.

It's just a (maybe crazy) idea, but if we're clever we might actually
get it to work. Of course, since you guys have a few different embedded
cores, that might be of more interest to your company than mine...

> > By the way, we booted with an initrd so we wouldn't need the network,
> > and hacked the device tree not to use interrupts for the UART. If you
> > take shortcuts like that you can really minimize your 
> > dependency on qemu for now.
> 
> How about the qemu position in our roadmap? If it still be the key role,
> I'll have to add some e500 hw drivers into it.

Yeah, that's a good question. I believe that emulating complex IP blocks
(e.g. IBM EMAC, Freescale TSEC) would take significant effort. Instead
I'm going to be trying alternatives, such as an x86-like "virtual board"
or virtual IO drivers.

In the first case, you pretend you have a bare core (without any SoC
peripherals) on a board with x86 devices. Qemu supports a set of x86
devices, so instead of writing all the TSEC emulation, you would just
tell the guest it has a Realtek NIC. Guests may already have device
drivers for "standard" devices like these.

Qemu will also gain virtual IO support in the future, which is basically
idealized IO devices to increase performance by using a
virtualization-friendly design (e.g. minimize MMIO accesses). The down
side is that guests would need new device drivers for this.

That said, we'd probably want to stick with emulated versions of
simple/critical PPC devices like the interrupt controller, so you might
have a little work to do there.

Personally I don't think writing all the SoC device emulation from
scratch is a realistic goal, at least not for me. You're welcome to
prioritize whatever you want of course. :)

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

 
> From: Hollis Blanchard [mailto:hollisb@us.ibm.com] 
> Sent: Thursday, December 13, 2007 3:19 AM
> > > 
> > > Congratulations! :) Will you send patches? What are your 
> > > thoughts on the
> > > commonality between 440 and e500 code?
> > 
> > Thanks! The MMU and some core registers are different, but 
> almost of the
> > other can be reused. So I change 440 TLB functions to core 
> independence
> > API and add an exceptions_e500.S file.
> 
> Interesting, good to know.
> 

I can take these changes into the new framework.
 
> > > We haven't touched the "hack" code recently, since we've been
> > > refactoring the upstream tree. That's pretty much done 
> > > though, and right
> > > now I'm just starting to integrate the old 440 support 
> with the new
> > > upstream code. That's not in a good state right now, but 
> I could clean
> > > it up and send it out if you're interested.
> > 
> > Yes! I think hack codes are only for verifying the idea. 
> Our target is
> > for upstream code. I hope I could join you!
> 
> Well, unfortunately at the moment I'm just fighting with
> asm-offsets.h . :( Since I'm basically already on vacation, 
> I'm not sure
> I'll be able to get anything ready until January.
> 

Do you mind send out the asm-offsets.h? Maybe I can take it base on the
hack code.

> > > Also, I'm messing around with Makefiles now, and have 
> been thinking
> > > about how to connect the modules... For example, should there be a
> > > kvm-powerpc-guest-440.ko that could link with 
> > > kvm-powerpc-host-e500.ko?
> > > For now, a single kvm-powerpc-e500.ko (e500 guests on 
> e500 host) is
> > > probably easiest, but we should think about the long-term 
> goal too.
> > > 
> > 
> > I will make some studies about this. What's kvm-guest-xxx.ko and
> > kvm-host-xxx.ko?
> > Why not one kvm-powerpc.ko?
> 
> Books 1 and 2 are (more or less) identical across PowerPC. Book 3 is
> where the big differences are, but we are emulating all Book 
> 3 stuff in
> software. That means we can emulate whatever Book 3 we want; we don't
> need to run only e500 guests on e500 hosts.
> 
> So, we could in theory have a module that e.g. emulates the 
> e500 Book 3,
> which we'd call something like kvm-powerpc-e500-guest.ko. If 
> we emulate
> tlbwe with HTAB modifications, we could run e500 guests on an e600. We
> would call the module with the HTAB logic something like
> kvm-powerpc-e600-host.ko.
> 

Oh, it is supposed to be a good idea. Howeve, can we know which target
the guest os is for, Book III-S or Book III-E(440, E500)?
If we can tell it, we could add supported guest module, such as 440,
e500, e600, into one fix table to fit the individual guest os.

> The important point for the MMU is that all PPC have the concept of a
> virtual address, which is an effective address + some context
> identifier. On classic or server PPC, that context comes from
> segmentation (SRs, SLB, or STAB), whereas on Book E the 
> context is AS +
> PID.
> 

In my ported 'hack' codes, I keep tlb APIs such as get_tlb_eaddr(),
get_tlb_ts(), but they weill be implemented by different core file. The
MMU instructure is the same, such as tlbwe. And I add some new TLB
feature bit definitions, such as TLBE_UR, TLBE_VALID.

> It's just a (maybe crazy) idea, but if we're clever we might actually
> get it to work. Of course, since you guys have a few 
> different embedded
> cores, that might be of more interest to your company than mine...
> 

:), I can take it.

> > > By the way, we booted with an initrd so we wouldn't need 
> the network,
> > > and hacked the device tree not to use interrupts for the 
> UART. If you
> > > take shortcuts like that you can really minimize your 
> > > dependency on qemu for now.
> > 
> > How about the qemu position in our roadmap? If it still be 
> the key role,
> > I'll have to add some e500 hw drivers into it.
> 
> Yeah, that's a good question. I believe that emulating 
> complex IP blocks
> (e.g. IBM EMAC, Freescale TSEC) would take significant effort. Instead
> I'm going to be trying alternatives, such as an x86-like 
> "virtual board"
> or virtual IO drivers.
> 
> In the first case, you pretend you have a bare core (without any SoC
> peripherals) on a board with x86 devices. Qemu supports a set of x86
> devices, so instead of writing all the TSEC emulation, you would just
> tell the guest it has a Realtek NIC. Guests may already have device
> drivers for "standard" devices like these.
> 

Good suggestion! I'm considering how to deal with the mpic and pci host
bridge.

> Qemu will also gain virtual IO support in the future, which 
> is basically
> idealized IO devices to increase performance by using a
> virtualization-friendly design (e.g. minimize MMIO accesses). The down
> side is that guests would need new device drivers for this.
> 
> That said, we'd probably want to stick with emulated versions of
> simple/critical PPC devices like the interrupt controller, so 
> you might
> have a little work to do there.
> 
> Personally I don't think writing all the SoC device emulation from
> scratch is a realistic goal, at least not for me. You're welcome to
> prioritize whatever you want of course. :)
> 

Agree! Writing all the SoC device emulation is crazy! :)

Thanks!
Wei.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Hollis Blanchard]

On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
> > From: Hollis Blanchard [mailto:hollisb@us.ibm.com] 
> > > > We haven't touched the "hack" code recently, since we've been
> > > > refactoring the upstream tree. That's pretty much done 
> > > > though, and right
> > > > now I'm just starting to integrate the old 440 support 
> > with the new
> > > > upstream code. That's not in a good state right now, but 
> > I could clean
> > > > it up and send it out if you're interested.
> > > 
> > > Yes! I think hack codes are only for verifying the idea. 
> > Our target is
> > > for upstream code. I hope I could join you!
> > 
> > Well, unfortunately at the moment I'm just fighting with
> > asm-offsets.h . :( Since I'm basically already on vacation, 
> > I'm not sure
> > I'll be able to get anything ready until January.
> > 
> 
> Do you mind send out the asm-offsets.h? Maybe I can take it base on the
> hack code.

Oh, the file is the same. The problem is how to have Kbuild
automatically generate it.

> > > > Also, I'm messing around with Makefiles now, and have 
> > been thinking
> > > > about how to connect the modules... For example, should there be a
> > > > kvm-powerpc-guest-440.ko that could link with 
> > > > kvm-powerpc-host-e500.ko?
> > > > For now, a single kvm-powerpc-e500.ko (e500 guests on 
> > e500 host) is
> > > > probably easiest, but we should think about the long-term 
> > goal too.
> > > > 
> > > 
> > > I will make some studies about this. What's kvm-guest-xxx.ko and
> > > kvm-host-xxx.ko?
> > > Why not one kvm-powerpc.ko?
> > 
> > Books 1 and 2 are (more or less) identical across PowerPC. Book 3 is
> > where the big differences are, but we are emulating all Book 
> > 3 stuff in
> > software. That means we can emulate whatever Book 3 we want; we don't
> > need to run only e500 guests on e500 hosts.
> > 
> > So, we could in theory have a module that e.g. emulates the 
> > e500 Book 3,
> > which we'd call something like kvm-powerpc-e500-guest.ko. If 
> > we emulate
> > tlbwe with HTAB modifications, we could run e500 guests on an e600. We
> > would call the module with the HTAB logic something like
> > kvm-powerpc-e600-host.ko.
> > 
> 
> Oh, it is supposed to be a good idea. Howeve, can we know which target
> the guest os is for, Book III-S or Book III-E(440, E500)?
> If we can tell it, we could add supported guest module, such as 440,
> e500, e600, into one fix table to fit the individual guest os.

I think that's a VM creation parameter. When userspace creates the VM
(including memory and vcpu allocation), it can specify to the kernel
which core to emulate.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang, Xiantao]

Hollis Blanchard wrote:
> On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
>>> From: Hollis Blanchard [mailto:hollisb@us.ibm.com]
>>>>> We haven't touched the "hack" code recently, since we've been
>>>>> refactoring the upstream tree. That's pretty much done
>>>>> though, and right
>>>>> now I'm just starting to integrate the old 440 support with the
>>>>> new upstream code. That's not in a good state right now, but I
>>>>> could clean it up and send it out if you're interested.
>>>> 
>>>> Yes! I think hack codes are only for verifying the idea. Our
>>>> target is for upstream code. I hope I could join you!
>>> 
>>> Well, unfortunately at the moment I'm just fighting with
>>> asm-offsets.h . :( Since I'm basically already on vacation,
>>> I'm not sure
>>> I'll be able to get anything ready until January.
>>> 
>> 
>> Do you mind send out the asm-offsets.h? Maybe I can take it base on
>> the hack code.
> 
> Oh, the file is the same. The problem is how to have Kbuild
> automatically generate it.

IA64 have the same issues , do you have good idea to handle it ?  Now, I
let kvm makefile to call a extenal script to solve it. :)

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

> Hollis Blanchard wrote:
> > On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
> >>> From: Hollis Blanchard [mailto:hollisb@us.ibm.com]
> >>>>> We haven't touched the "hack" code recently, since we've been
> >>>>> refactoring the upstream tree. That's pretty much done
> >>>>> though, and right
> >>>>> now I'm just starting to integrate the old 440 support with the
> >>>>> new upstream code. That's not in a good state right now, but I
> >>>>> could clean it up and send it out if you're interested.
> >>>> 
> >>>> Yes! I think hack codes are only for verifying the idea. Our
> >>>> target is for upstream code. I hope I could join you!
> >>> 
> >>> Well, unfortunately at the moment I'm just fighting with
> >>> asm-offsets.h . :( Since I'm basically already on vacation,
> >>> I'm not sure
> >>> I'll be able to get anything ready until January.
> >>> 
> >> 
> >> Do you mind send out the asm-offsets.h? Maybe I can take it base on
> >> the hack code.
> > 
> > Oh, the file is the same. The problem is how to have Kbuild
> > automatically generate it.
> 
> IA64 have the same issues , do you have good idea to handle 
> it ?  Now, I
> let kvm makefile to call a extenal script to solve it. :)
> 

Do you mean if you change the struct kvm_vcpu of the kvm.h file, but the
asm-offsets.h file can not be re-generated by your current Makefile?

If it is, you can modify Makefile as below:
- $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c
+ $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE

Or is there any other problems about asm-offsets.h in Makefile?

Cheers!
Wei

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Hollis Blanchard]

On Fri, 2007-12-14 at 14:15 +0800, Zhang Wei wrote:
> > Hollis Blanchard wrote:
> > > On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
> > >>> From: Hollis Blanchard [mailto:hollisb@us.ibm.com]
> > >>>>> We haven't touched the "hack" code recently, since we've been
> > >>>>> refactoring the upstream tree. That's pretty much done
> > >>>>> though, and right
> > >>>>> now I'm just starting to integrate the old 440 support with the
> > >>>>> new upstream code. That's not in a good state right now, but I
> > >>>>> could clean it up and send it out if you're interested.
> > >>>> 
> > >>>> Yes! I think hack codes are only for verifying the idea. Our
> > >>>> target is for upstream code. I hope I could join you!
> > >>> 
> > >>> Well, unfortunately at the moment I'm just fighting with
> > >>> asm-offsets.h . :( Since I'm basically already on vacation,
> > >>> I'm not sure
> > >>> I'll be able to get anything ready until January.
> > >>> 
> > >> 
> > >> Do you mind send out the asm-offsets.h? Maybe I can take it base on
> > >> the hack code.
> > > 
> > > Oh, the file is the same. The problem is how to have Kbuild
> > > automatically generate it.
> > 
> > IA64 have the same issues , do you have good idea to handle 
> > it ?  Now, I
> > let kvm makefile to call a extenal script to solve it. :)
> > 
> 
> Do you mean if you change the struct kvm_vcpu of the kvm.h file, but the
> asm-offsets.h file can not be re-generated by your current Makefile?
> 
> If it is, you can modify Makefile as below:
> - $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c
> + $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE
> 
> Or is there any other problems about asm-offsets.h in Makefile?

Yes, there is a larger problem: forget the dependencies; how do we
generate asm-offsets.h in the first place? The Makefile hackery that
I've posted before is not a good solution, and I'm looking for that good
solution.

IA64 needs to generate its own asm-offsets too, and so does lguest.
That's why I've been looking at the "mkasm-values" patches recently
(google it)...

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang, Xiantao]

Hollis Blanchard wrote:
> On Fri, 2007-12-14 at 14:15 +0800, Zhang Wei wrote:
>>> Hollis Blanchard wrote:
>>>> On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
>>>>>> From: Hollis Blanchard [mailto:hollisb@us.ibm.com]
>>>>>>>> We haven't touched the "hack" code recently, since we've been
>>>>>>>> refactoring the upstream tree. That's pretty much done
>>>>>>>> though, and right
>>>>>>>> now I'm just starting to integrate the old 440 support with the
>>>>>>>> new upstream code. That's not in a good state right now, but I
>>>>>>>> could clean it up and send it out if you're interested.
>>>>>>> 
>>>>>>> Yes! I think hack codes are only for verifying the idea. Our
>>>>>>> target is for upstream code. I hope I could join you!
>>>>>> 
>>>>>> Well, unfortunately at the moment I'm just fighting with
>>>>>> asm-offsets.h . :( Since I'm basically already on vacation, I'm
>>>>>> not sure I'll be able to get anything ready until January.
>>>>>> 
>>>>> 
>>>>> Do you mind send out the asm-offsets.h? Maybe I can take it base
>>>>> on the hack code.
>>>> 
>>>> Oh, the file is the same. The problem is how to have Kbuild
>>>> automatically generate it.
>>> 
>>> IA64 have the same issues , do you have good idea to handle it ? 
>>> Now, I let kvm makefile to call a extenal script to solve it. :)
>>> 
>> 
>> Do you mean if you change the struct kvm_vcpu of the kvm.h file, but
>> the asm-offsets.h file can not be re-generated by your current
>> Makefile? 
>> 
>> If it is, you can modify Makefile as below:
>> - $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c
>> + $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE
>> 
>> Or is there any other problems about asm-offsets.h in Makefile?
> 
> Yes, there is a larger problem: forget the dependencies; how do we
> generate asm-offsets.h in the first place? The Makefile hackery that
> I've posted before is not a good solution, and I'm looking for that
> good solution.

I have a solution, but don't know this is the best one.  According to
the rules, all c or asm files should depend on 
FORCE, so in your own Makefile, you can set FORCE: asm-offsets.h ,
asm-offsets.h should be compiled before any 
Source files:)


> IA64 needs to generate its own asm-offsets too, and so does lguest.
> That's why I've been looking at the "mkasm-values" patches recently
> (google it)...


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang, Xiantao]

Hollis Blanchard wrote:
> On Fri, 2007-12-14 at 14:15 +0800, Zhang Wei wrote:
>>> Hollis Blanchard wrote:
>>>> On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
>>>>>> From: Hollis Blanchard [mailto:hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org]
>>>>>>>> We haven't touched the "hack" code recently, since we've been
>>>>>>>> refactoring the upstream tree. That's pretty much done
>>>>>>>> though, and right
>>>>>>>> now I'm just starting to integrate the old 440 support with the
>>>>>>>> new upstream code. That's not in a good state right now, but I
>>>>>>>> could clean it up and send it out if you're interested.
>>>>>>> 
>>>>>>> Yes! I think hack codes are only for verifying the idea. Our
>>>>>>> target is for upstream code. I hope I could join you!
>>>>>> 
>>>>>> Well, unfortunately at the moment I'm just fighting with
>>>>>> asm-offsets.h . :( Since I'm basically already on vacation, I'm
>>>>>> not sure I'll be able to get anything ready until January.
>>>>>> 
>>>>> 
>>>>> Do you mind send out the asm-offsets.h? Maybe I can take it base
>>>>> on the hack code.
>>>> 
>>>> Oh, the file is the same. The problem is how to have Kbuild
>>>> automatically generate it.
>>> 
>>> IA64 have the same issues , do you have good idea to handle it ? 
>>> Now, I let kvm makefile to call a extenal script to solve it. :)
>>> 
>> 
>> Do you mean if you change the struct kvm_vcpu of the kvm.h file, but
>> the asm-offsets.h file can not be re-generated by your current
>> Makefile? 
>> 
>> If it is, you can modify Makefile as below:
>> - $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c
>> + $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE
>> 
>> Or is there any other problems about asm-offsets.h in Makefile?
> 
> Yes, there is a larger problem: forget the dependencies; how do we
> generate asm-offsets.h in the first place? The Makefile hackery that
> I've posted before is not a good solution, and I'm looking for that
> good solution.

I have a solution, but don't know this is the best one.  According to
the rules, all c or asm files should depend on 
FORCE, so in your own Makefile, you can set FORCE: asm-offsets.h ,
asm-offsets.h should be compiled before any 
Source files:)


> IA64 needs to generate its own asm-offsets too, and so does lguest.
> That's why I've been looking at the "mkasm-values" patches recently
> (google it)...


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

> From: kvm-ppc-devel-bounces@lists.sourceforge.net 
> [mailto:kvm-ppc-devel-bounces@lists.sourceforge.net] On 
> Behalf Of Hollis Blanchard
> On Fri, 2007-12-14 at 14:15 +0800, Zhang Wei wrote:
> > > Hollis Blanchard wrote:
> > > > On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote:
> > > >>> From: Hollis Blanchard [mailto:hollisb@us.ibm.com]
> > > >>>>> We haven't touched the "hack" code recently, since 
> we've been
> > > >>>>> refactoring the upstream tree. That's pretty much done
> > > >>>>> though, and right
> > > >>>>> now I'm just starting to integrate the old 440 
> support with the
> > > >>>>> new upstream code. That's not in a good state right 
> now, but I
> > > >>>>> could clean it up and send it out if you're interested.
> > > >>>> 
> > > >>>> Yes! I think hack codes are only for verifying the idea. Our
> > > >>>> target is for upstream code. I hope I could join you!
> > > >>> 
> > > >>> Well, unfortunately at the moment I'm just fighting with
> > > >>> asm-offsets.h . :( Since I'm basically already on vacation,
> > > >>> I'm not sure
> > > >>> I'll be able to get anything ready until January.
> > > >>> 
> > > >> 
> > > >> Do you mind send out the asm-offsets.h? Maybe I can 
> take it base on
> > > >> the hack code.
> > > > 
> > > > Oh, the file is the same. The problem is how to have Kbuild
> > > > automatically generate it.
> > > 
> > > IA64 have the same issues , do you have good idea to handle 
> > > it ?  Now, I
> > > let kvm makefile to call a extenal script to solve it. :)
> > > 
> > 
> > Do you mean if you change the struct kvm_vcpu of the kvm.h 
> file, but the
> > asm-offsets.h file can not be re-generated by your current Makefile?
> > 
> > If it is, you can modify Makefile as below:
> > - $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c
> > + $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE
> > 
> > Or is there any other problems about asm-offsets.h in Makefile?
> 
> Yes, there is a larger problem: forget the dependencies; how do we
> generate asm-offsets.h in the first place? The Makefile hackery that
> I've posted before is not a good solution, and I'm looking 
> for that good
> solution.
> 
> IA64 needs to generate its own asm-offsets too, and so does lguest.
> That's why I've been looking at the "mkasm-values" patches recently
> (google it)...
> 

I've found "mkasm-values" patches, but it's pity that they are not
accepted yet. I've similar codes of yours in Makefile of root directory.
Maybe it's not the best solution, but acceptable. We can keep it and
wait for "mkasm-values" patches. How about?

Cheers!
Wei

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Current e500 kvm guest kernel

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Hollis already pointed me to the mkasm-values patches which are the continuation of the mkasm-offset discussion on lkml Hollis last patch was based on.
As stated before by Xiantao and Hollis in this thread the mkasm-value patches are not yet accepted upstream, but may be useful for us.
Based on Hollis old mkasm-offsets patch, the further discussion on lkml and Xiantaos suggestion about the FORCE target I created a mkasm-values patch that now is at least able to do what we need for ppc and should fit the ia64 needs too.
We might use it internally until mkasm-values is accepted in any way or in a local form like ia64 that currently use their own script - let us at least use a common one together and mkasm-values may be a good base for that ;-)
The current patch is for discussion only because it won't fit git head of avi's tree - I need to rebase Hollis tree first and I'll send an update once I get around to do it.

The patch work to create, and re-generate asm-values.h as we need it and since now every architecture has its own arch/kvm&asm directory we can even keep the name "asm-values.h" the lkml patches expect. Because these preview patches are for discussion only I attach both to this mail instead of sending standard [patch][x/y] mails.

@Zhang Wai - afaik you use Hollis kvmppc development tree, you can just remove the old mkasm-offset patch and add these two to get the offset stuff to work for now

-- 

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt@linux.vnet.ibm.com
Ehrhardt@de.ibm.com

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen 
Geschäftsführung: Herbert Kircher 
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

[-- Attachment #2: mkasm-values-new --]
[-- Type: text/plain, Size: 2483 bytes --]

diff -r 78da6ce942cc include/asm-generic/asm-values.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/include/asm-generic/asm-values.h	Mon Dec 17 13:38:19 2007 +0100
@@ -0,0 +1,7 @@
+#define DEFINE(sym, val) \
+	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+
+#define BLANK() asm volatile("\n->" : : )
+
+#define OFFSET(sym, str, mem) \
+	DEFINE(sym, offsetof(struct str, mem));
diff -r 78da6ce942cc scripts/Makefile.asm
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/Makefile.asm	Tue Dec 18 10:36:48 2007 +0100
@@ -0,0 +1,29 @@
+# ==========================================================================
+# Help generate definitions needed by assembly language modules.
+# ==========================================================================
+
+include scripts/Kbuild.include
+
+ifndef asm-values_h
+    asm-values := $(shell test -e $(srctree)/$(src)/asm-values.c && echo ok)
+    ifneq ($(asm-values),)
+	asm-values_h := asm-values.h
+	asm-values   := asm-values.s
+    endif
+endif
+
+always		+= $(asm-values_h)
+targets		+= $(asm-values_h) $(asm-values)
+mkasm-values	:= $(srctree)/scripts/mkasm-values.sh
+
+quiet_cmd_mkasm-values = GEN     $@
+      cmd_mkasm-values = $(CONFIG_SHELL) $(mkasm-values) $< $@ $(2)
+
+quiet_cmd_cc_s_c = CC $(quiet_modtag)  $@
+      cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $<
+
+$(obj)/asm-values.h: $(obj)/asm-values.s
+	$(call cmd,mkasm-values,$(ASM_NS))
+
+$(obj)/%.s: $(src)/%.c
+	$(call if_changed_dep,cc_s_c)
diff -r 78da6ce942cc scripts/mkasm-values.sh
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/mkasm-values.sh	Mon Dec 17 13:38:19 2007 +0100
@@ -0,0 +1,55 @@
+#!/bin/sh
+
+# Input file "*.s", made by Kbuild from a "*.c" source, where values of
+# interest are calculated, is processed in a suitable output header file.
+#
+# $1 - input filename;
+# $2 - output filename;
+# $3 - generate (private) file with given namespace (optional)
+
+set -e
+
+[ -z "$1" ] || [ -z "$2" ] && {
+	echo "$0:
+
+Two parameters needed. Exiting.
+"
+	exit 1
+}
+
+NS=`echo $3 | tr a-z A-Z`
+case $NS in
+	MIPS)
+SED_SCRIPT='
+/^@@@/{
+s|^@@@||;
+s| #.*$||;
+p;
+}'	;;
+	*)
+TAB="`printf '\t'`"
+SED_SCRIPT="
+/^->/{
+s|^->||;
+s|^\([^ ]*\) [\$#]*\([^ ]*\) \([^$TAB]*\).*|#define \1 \2$TAB/* \3 */|;
+p;
+}"	;;
+esac
+
+NS=__ASM_VALUES_${NS:=H}__
+
+exec 1>$2
+echo "\
+#if !defined($NS)
+#define $NS
+
+/*
+ * $2
+ * was generated from
+ * $1
+ */
+"
+sed -ne "$SED_SCRIPT" $1
+
+echo "
+#endif"

[-- Attachment #3: use-mkasm-for-kvm-powerpc --]
[-- Type: text/plain, Size: 3944 bytes --]

diff -r 1b4814a8e0ed drivers/kvm/Makefile
--- a/drivers/kvm/Makefile	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/Makefile	Tue Dec 18 10:37:37 2007 +0100
@@ -14,7 +14,7 @@ kvm-amd-objs = svm.o
 kvm-amd-objs = svm.o
 obj-$(CONFIG_KVM_AMD) += kvm-amd.o
 
+include $(srctree)/scripts/Makefile.asm
+FORCE: $(obj)/asm-values.h
 kvm-powerpc-objs := powerpc.o ppc_emulate.o ppc_tlb.o ppc_44x_exceptions.o
 obj-$(CONFIG_KVM_POWERPC) += kvm-powerpc.o
-
-AFLAGS_ppc_44x_exceptions.o := -I$(obj)
diff -r 1b4814a8e0ed drivers/kvm/ppc-offsets.c
--- a/drivers/kvm/ppc-offsets.c	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/ppc-offsets.c	Tue Dec 18 10:37:37 2007 +0100
@@ -21,38 +21,36 @@
 #include <linux/stddef.h>
 #include <linux/types.h>
 #include "kvm.h"
-
-#define DEFINE(sym, val) \
-	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+#include <asm-generic/asm-values.h>
 
 int main(void)
 {
 	DEFINE(TLBE_BYTES, sizeof(struct tlbe));
 
-	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, host_stack));
-	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, host_pid));
-	DEFINE(VCPU_HOST_TLB, offsetof(struct kvm_vcpu, host_tlb));
-	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, shadow_tlb));
-	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, gpr));
-	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, lr));
-	DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, cr));
-	DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, xer));
-	DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, ctr));
-	DEFINE(VCPU_PC, offsetof(struct kvm_vcpu, pc));
-	DEFINE(VCPU_GUEST_MSR, offsetof(struct kvm_vcpu, guest_msr));
-	DEFINE(VCPU_SHADOW_MSR, offsetof(struct kvm_vcpu, shadow_msr));
-	DEFINE(VCPU_SPRG4, offsetof(struct kvm_vcpu, sprg4));
-	DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, sprg5));
-	DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, sprg6));
-	DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, sprg7));
-	DEFINE(VCPU_PID, offsetof(struct kvm_vcpu, pid));
+	OFFSET(VCPU_HOST_STACK, struct kvm_vcpu, host_stack);
+	OFFSET(VCPU_HOST_PID, struct kvm_vcpu, host_pid);
+	OFFSET(VCPU_HOST_TLB, struct kvm_vcpu, host_tlb);
+	OFFSET(VCPU_SHADOW_TLB, struct kvm_vcpu, shadow_tlb);
+	OFFSET(VCPU_GPRS, struct kvm_vcpu, gpr);
+	OFFSET(VCPU_LR, struct kvm_vcpu, lr);
+	OFFSET(VCPU_CR, struct kvm_vcpu, cr);
+	OFFSET(VCPU_XER, struct kvm_vcpu, xer);
+	OFFSET(VCPU_CTR, struct kvm_vcpu, ctr);
+	OFFSET(VCPU_PC, struct kvm_vcpu, pc);
+	OFFSET(VCPU_GUEST_MSR, struct kvm_vcpu, guest_msr);
+	OFFSET(VCPU_SHADOW_MSR, struct kvm_vcpu, shadow_msr);
+	OFFSET(VCPU_SPRG4, struct kvm_vcpu, sprg4);
+	OFFSET(VCPU_SPRG5, struct kvm_vcpu, sprg5);
+	OFFSET(VCPU_SPRG6, struct kvm_vcpu, sprg6);
+	OFFSET(VCPU_SPRG7, struct kvm_vcpu, sprg7);
+	OFFSET(VCPU_PID, struct kvm_vcpu, pid);
 
-	DEFINE(VCPU_TRAMPOLINE, offsetof(struct kvm_vcpu, trampoline));
-	DEFINE(VCPU_TRAMPOLINE_TLBE, offsetof(struct kvm_vcpu, trampoline_tlbe));
-	DEFINE(VCPU_LINEAR, offsetof(struct kvm_vcpu, linear));
-	DEFINE(VCPU_RESUME_GUEST, offsetof(struct kvm_vcpu, resume_guest));
-	DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, last_inst));
-	DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, fault_dear));
-	DEFINE(VCPU_FAULT_ESR, offsetof(struct kvm_vcpu, fault_esr));
+	OFFSET(VCPU_TRAMPOLINE, struct kvm_vcpu, trampoline);
+	OFFSET(VCPU_TRAMPOLINE_TLBE, struct kvm_vcpu, trampoline_tlbe);
+	OFFSET(VCPU_LINEAR, struct kvm_vcpu, linear);
+	OFFSET(VCPU_RESUME_GUEST, struct kvm_vcpu, resume_guest);
+	OFFSET(VCPU_LAST_INST, struct kvm_vcpu, last_inst);
+	OFFSET(VCPU_FAULT_DEAR, struct kvm_vcpu, fault_dear);
+	OFFSET(VCPU_FAULT_ESR, struct kvm_vcpu, fault_esr);
 	return 0;
 }
diff -r 1b4814a8e0ed drivers/kvm/ppc_44x_exceptions.S
--- a/drivers/kvm/ppc_44x_exceptions.S	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/ppc_44x_exceptions.S	Tue Dec 18 10:37:37 2007 +0100
@@ -24,7 +24,7 @@
 #include <asm/page.h>
 
 #include "powerpc.h"
-#include "ppc-offsets.h"
+#include "asm-values.h"
 
 #define VCPU_GPR(n)     (VCPU_GPRS + (n * 4))
 

[-- Attachment #4: Type: text/plain, Size: 308 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[-- Attachment #5: Type: text/plain, Size: 170 bytes --]

_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

Hollis already pointed me to the mkasm-values patches which are the continuation of the mkasm-offset discussion on lkml Hollis last patch was based on.
As stated before by Xiantao and Hollis in this thread the mkasm-value patches are not yet accepted upstream, but may be useful for us.
Based on Hollis old mkasm-offsets patch, the further discussion on lkml and Xiantaos suggestion about the FORCE target I created a mkasm-values patch that now is at least able to do what we need for ppc and should fit the ia64 needs too.
We might use it internally until mkasm-values is accepted in any way or in a local form like ia64 that currently use their own script - let us at least use a common one together and mkasm-values may be a good base for that ;-)
The current patch is for discussion only because it won't fit git head of avi's tree - I need to rebase Hollis tree first and I'll send an update once I get around to do it.

The patch work to create, and re-generate asm-values.h as we need it and since now every architecture has its own arch/kvm&asm directory we can even keep the name "asm-values.h" the lkml patches expect. Because these preview patches are for discussion only I attach both to this mail instead of sending standard [patch][x/y] mails.

@Zhang Wai - afaik you use Hollis kvmppc development tree, you can just remove the old mkasm-offset patch and add these two to get the offset stuff to work for now

-- 

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org
Ehrhardt-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen 
Geschäftsführung: Herbert Kircher 
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

[-- Attachment #2: mkasm-values-new --]
[-- Type: text/plain, Size: 2483 bytes --]

diff -r 78da6ce942cc include/asm-generic/asm-values.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/include/asm-generic/asm-values.h	Mon Dec 17 13:38:19 2007 +0100
@@ -0,0 +1,7 @@
+#define DEFINE(sym, val) \
+	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+
+#define BLANK() asm volatile("\n->" : : )
+
+#define OFFSET(sym, str, mem) \
+	DEFINE(sym, offsetof(struct str, mem));
diff -r 78da6ce942cc scripts/Makefile.asm
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/Makefile.asm	Tue Dec 18 10:36:48 2007 +0100
@@ -0,0 +1,29 @@
+# ==========================================================================
+# Help generate definitions needed by assembly language modules.
+# ==========================================================================
+
+include scripts/Kbuild.include
+
+ifndef asm-values_h
+    asm-values := $(shell test -e $(srctree)/$(src)/asm-values.c && echo ok)
+    ifneq ($(asm-values),)
+	asm-values_h := asm-values.h
+	asm-values   := asm-values.s
+    endif
+endif
+
+always		+= $(asm-values_h)
+targets		+= $(asm-values_h) $(asm-values)
+mkasm-values	:= $(srctree)/scripts/mkasm-values.sh
+
+quiet_cmd_mkasm-values = GEN     $@
+      cmd_mkasm-values = $(CONFIG_SHELL) $(mkasm-values) $< $@ $(2)
+
+quiet_cmd_cc_s_c = CC $(quiet_modtag)  $@
+      cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $<
+
+$(obj)/asm-values.h: $(obj)/asm-values.s
+	$(call cmd,mkasm-values,$(ASM_NS))
+
+$(obj)/%.s: $(src)/%.c
+	$(call if_changed_dep,cc_s_c)
diff -r 78da6ce942cc scripts/mkasm-values.sh
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/scripts/mkasm-values.sh	Mon Dec 17 13:38:19 2007 +0100
@@ -0,0 +1,55 @@
+#!/bin/sh
+
+# Input file "*.s", made by Kbuild from a "*.c" source, where values of
+# interest are calculated, is processed in a suitable output header file.
+#
+# $1 - input filename;
+# $2 - output filename;
+# $3 - generate (private) file with given namespace (optional)
+
+set -e
+
+[ -z "$1" ] || [ -z "$2" ] && {
+	echo "$0:
+
+Two parameters needed. Exiting.
+"
+	exit 1
+}
+
+NS=`echo $3 | tr a-z A-Z`
+case $NS in
+	MIPS)
+SED_SCRIPT='
+/^@@@/{
+s|^@@@||;
+s| #.*$||;
+p;
+}'	;;
+	*)
+TAB="`printf '\t'`"
+SED_SCRIPT="
+/^->/{
+s|^->||;
+s|^\([^ ]*\) [\$#]*\([^ ]*\) \([^$TAB]*\).*|#define \1 \2$TAB/* \3 */|;
+p;
+}"	;;
+esac
+
+NS=__ASM_VALUES_${NS:=H}__
+
+exec 1>$2
+echo "\
+#if !defined($NS)
+#define $NS
+
+/*
+ * $2
+ * was generated from
+ * $1
+ */
+"
+sed -ne "$SED_SCRIPT" $1
+
+echo "
+#endif"

[-- Attachment #3: use-mkasm-for-kvm-powerpc --]
[-- Type: text/plain, Size: 3944 bytes --]

diff -r 1b4814a8e0ed drivers/kvm/Makefile
--- a/drivers/kvm/Makefile	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/Makefile	Tue Dec 18 10:37:37 2007 +0100
@@ -14,7 +14,7 @@ kvm-amd-objs = svm.o
 kvm-amd-objs = svm.o
 obj-$(CONFIG_KVM_AMD) += kvm-amd.o
 
+include $(srctree)/scripts/Makefile.asm
+FORCE: $(obj)/asm-values.h
 kvm-powerpc-objs := powerpc.o ppc_emulate.o ppc_tlb.o ppc_44x_exceptions.o
 obj-$(CONFIG_KVM_POWERPC) += kvm-powerpc.o
-
-AFLAGS_ppc_44x_exceptions.o := -I$(obj)
diff -r 1b4814a8e0ed drivers/kvm/ppc-offsets.c
--- a/drivers/kvm/ppc-offsets.c	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/ppc-offsets.c	Tue Dec 18 10:37:37 2007 +0100
@@ -21,38 +21,36 @@
 #include <linux/stddef.h>
 #include <linux/types.h>
 #include "kvm.h"
-
-#define DEFINE(sym, val) \
-	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
+#include <asm-generic/asm-values.h>
 
 int main(void)
 {
 	DEFINE(TLBE_BYTES, sizeof(struct tlbe));
 
-	DEFINE(VCPU_HOST_STACK, offsetof(struct kvm_vcpu, host_stack));
-	DEFINE(VCPU_HOST_PID, offsetof(struct kvm_vcpu, host_pid));
-	DEFINE(VCPU_HOST_TLB, offsetof(struct kvm_vcpu, host_tlb));
-	DEFINE(VCPU_SHADOW_TLB, offsetof(struct kvm_vcpu, shadow_tlb));
-	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, gpr));
-	DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, lr));
-	DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, cr));
-	DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, xer));
-	DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, ctr));
-	DEFINE(VCPU_PC, offsetof(struct kvm_vcpu, pc));
-	DEFINE(VCPU_GUEST_MSR, offsetof(struct kvm_vcpu, guest_msr));
-	DEFINE(VCPU_SHADOW_MSR, offsetof(struct kvm_vcpu, shadow_msr));
-	DEFINE(VCPU_SPRG4, offsetof(struct kvm_vcpu, sprg4));
-	DEFINE(VCPU_SPRG5, offsetof(struct kvm_vcpu, sprg5));
-	DEFINE(VCPU_SPRG6, offsetof(struct kvm_vcpu, sprg6));
-	DEFINE(VCPU_SPRG7, offsetof(struct kvm_vcpu, sprg7));
-	DEFINE(VCPU_PID, offsetof(struct kvm_vcpu, pid));
+	OFFSET(VCPU_HOST_STACK, struct kvm_vcpu, host_stack);
+	OFFSET(VCPU_HOST_PID, struct kvm_vcpu, host_pid);
+	OFFSET(VCPU_HOST_TLB, struct kvm_vcpu, host_tlb);
+	OFFSET(VCPU_SHADOW_TLB, struct kvm_vcpu, shadow_tlb);
+	OFFSET(VCPU_GPRS, struct kvm_vcpu, gpr);
+	OFFSET(VCPU_LR, struct kvm_vcpu, lr);
+	OFFSET(VCPU_CR, struct kvm_vcpu, cr);
+	OFFSET(VCPU_XER, struct kvm_vcpu, xer);
+	OFFSET(VCPU_CTR, struct kvm_vcpu, ctr);
+	OFFSET(VCPU_PC, struct kvm_vcpu, pc);
+	OFFSET(VCPU_GUEST_MSR, struct kvm_vcpu, guest_msr);
+	OFFSET(VCPU_SHADOW_MSR, struct kvm_vcpu, shadow_msr);
+	OFFSET(VCPU_SPRG4, struct kvm_vcpu, sprg4);
+	OFFSET(VCPU_SPRG5, struct kvm_vcpu, sprg5);
+	OFFSET(VCPU_SPRG6, struct kvm_vcpu, sprg6);
+	OFFSET(VCPU_SPRG7, struct kvm_vcpu, sprg7);
+	OFFSET(VCPU_PID, struct kvm_vcpu, pid);
 
-	DEFINE(VCPU_TRAMPOLINE, offsetof(struct kvm_vcpu, trampoline));
-	DEFINE(VCPU_TRAMPOLINE_TLBE, offsetof(struct kvm_vcpu, trampoline_tlbe));
-	DEFINE(VCPU_LINEAR, offsetof(struct kvm_vcpu, linear));
-	DEFINE(VCPU_RESUME_GUEST, offsetof(struct kvm_vcpu, resume_guest));
-	DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, last_inst));
-	DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu, fault_dear));
-	DEFINE(VCPU_FAULT_ESR, offsetof(struct kvm_vcpu, fault_esr));
+	OFFSET(VCPU_TRAMPOLINE, struct kvm_vcpu, trampoline);
+	OFFSET(VCPU_TRAMPOLINE_TLBE, struct kvm_vcpu, trampoline_tlbe);
+	OFFSET(VCPU_LINEAR, struct kvm_vcpu, linear);
+	OFFSET(VCPU_RESUME_GUEST, struct kvm_vcpu, resume_guest);
+	OFFSET(VCPU_LAST_INST, struct kvm_vcpu, last_inst);
+	OFFSET(VCPU_FAULT_DEAR, struct kvm_vcpu, fault_dear);
+	OFFSET(VCPU_FAULT_ESR, struct kvm_vcpu, fault_esr);
 	return 0;
 }
diff -r 1b4814a8e0ed drivers/kvm/ppc_44x_exceptions.S
--- a/drivers/kvm/ppc_44x_exceptions.S	Tue Dec 18 10:37:21 2007 +0100
+++ b/drivers/kvm/ppc_44x_exceptions.S	Tue Dec 18 10:37:37 2007 +0100
@@ -24,7 +24,7 @@
 #include <asm/page.h>
 
 #include "powerpc.h"
-#include "ppc-offsets.h"
+#include "asm-values.h"
 
 #define VCPU_GPR(n)     (VCPU_GPRS + (n * 4))
 

[-- Attachment #4: Type: text/plain, Size: 308 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[-- Attachment #5: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-ppc-devel] [kvm-devel] Current e500 kvm guest kernel

[Zhang Wei]

> 
> Hollis already pointed me to the mkasm-values patches which 
> are the continuation of the mkasm-offset discussion on lkml 
> Hollis last patch was based on.
> As stated before by Xiantao and Hollis in this thread the 
> mkasm-value patches are not yet accepted upstream, but may be 
> useful for us.
> Based on Hollis old mkasm-offsets patch, the further 
> discussion on lkml and Xiantaos suggestion about the FORCE 
> target I created a mkasm-values patch that now is at least 
> able to do what we need for ppc and should fit the ia64 needs too.
> We might use it internally until mkasm-values is accepted in 
> any way or in a local form like ia64 that currently use their 
> own script - let us at least use a common one together and 
> mkasm-values may be a good base for that ;-)
> The current patch is for discussion only because it won't fit 
> git head of avi's tree - I need to rebase Hollis tree first 
> and I'll send an update once I get around to do it.
> 
> The patch work to create, and re-generate asm-values.h as we 
> need it and since now every architecture has its own 
> arch/kvm&asm directory we can even keep the name 
> "asm-values.h" the lkml patches expect. Because these preview 
> patches are for discussion only I attach both to this mail 
> instead of sending standard [patch][x/y] mails.
> 
> @Zhang Wai - afaik you use Hollis kvmppc development tree, 
> you can just remove the old mkasm-offset patch and add these 
> two to get the offset stuff to work for now
> 

Good!
I'll continue my jobs. Thanks!

Cheers!
Wei.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] Current e500 kvm guest kernel booting log

[Zhang Wei]

> 
> Hollis already pointed me to the mkasm-values patches which 
> are the continuation of the mkasm-offset discussion on lkml 
> Hollis last patch was based on.
> As stated before by Xiantao and Hollis in this thread the 
> mkasm-value patches are not yet accepted upstream, but may be 
> useful for us.
> Based on Hollis old mkasm-offsets patch, the further 
> discussion on lkml and Xiantaos suggestion about the FORCE 
> target I created a mkasm-values patch that now is at least 
> able to do what we need for ppc and should fit the ia64 needs too.
> We might use it internally until mkasm-values is accepted in 
> any way or in a local form like ia64 that currently use their 
> own script - let us at least use a common one together and 
> mkasm-values may be a good base for that ;-)
> The current patch is for discussion only because it won't fit 
> git head of avi's tree - I need to rebase Hollis tree first 
> and I'll send an update once I get around to do it.
> 
> The patch work to create, and re-generate asm-values.h as we 
> need it and since now every architecture has its own 
> arch/kvm&asm directory we can even keep the name 
> "asm-values.h" the lkml patches expect. Because these preview 
> patches are for discussion only I attach both to this mail 
> instead of sending standard [patch][x/y] mails.
> 
> @Zhang Wai - afaik you use Hollis kvmppc development tree, 
> you can just remove the old mkasm-offset patch and add these 
> two to get the offset stuff to work for now
> 

Good!
I'll continue my jobs. Thanks!

Cheers!
Wei.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace