Re: [Minios-devel] [PATCH 05/40] arm64: fix the wrong mask for to_virt/to_phys

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Shijie,

On 07/11/2017 08:22, Huang Shijie wrote:
> On Mon, Nov 06, 2017 at 11:09:46AM +0000, Julien Grall wrote:
> > On 06/11/17 09:48, Huang Shijie wrote:
> > > On Fri, Nov 03, 2017 at 03:03:16PM +0000, Julien Grall wrote:
> > > > On 03/11/17 03:11, Huang Shijie wrote:
> > > > > +#endif
> > > > > +
> > > > > +#define to_phys(x)                 (((paddr_t)(x)-physical_address_offset) & 
> > > > > ADDR_MASK)
> > > > Why did you switch from an addition to a subtraction?
> > > >
> > > > > +#define to_virt(x)                 ((void *)(((x)+physical_address_offset) & 
> > > > > ADDR_MASK))
> > > > Why did you switch from a subtraction to an addition?
> > > I do not have an arm32 platform.
> > Well, you said you tested on softiron which support 32-bit guests. So what's
> > the problem?
> >
> > But I am struggling to understand why in some places you say: "This does not
> > work for arm32". Implying you tested it. And here you say: "I don't have any
> > platform".
> I added some hack code to pass the arm32 compiler, and tested in the
> softiron platform: Please see the log :
>   
> -------------------------------------------------------------------------------
>   [ == ROOT@ Softiron -- Ubuntu ~ == ] #xl create -c mini-os-arm32.conf
>   Parsing config from mini-os-arm32.conf
>   libxl: error: libxl_arm.c:603:get_arch_info: Unable to find arch FDT info for 
> xen-3.0-unknown
>   libxl: error: libxl_dom.c:660:libxl__build_dom: 
> libxl__arch_domain_init_hw_description failed: No such file or directory
>   libxl: error: libxl_create.c:1217:domcreate_rebuild_done: Domain 6:cannot 
> (re-)build domain: -3
>   libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 6:Non-existant 
> domain
>   libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 6:Unable to 
> destroy guest
>   libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 6:Destruction of 
> domain failed
>    
> -------------------------------------------------------------------------------
I already gave suggestion in an e-mail directly to you yesterday... Did 
you have a look at it?
FIY that was:

"What image do you pass to guest? It likely looks you pass an ELF and 
not an image following the arm32 Linux Image format."
> > AFAICT, there are no way to compile Arm with current master:
> >
> > make TARGET_ARCH_FAM=arm
> >
> >
> >
> > Config.mk:93: /home/julieng/works/mini-os/arch/arm/arch.mk: No such file or
> > directory
> > make: *** No rule to make target
> > '/home/julieng/works/mini-os/arch/arm/arch.mk'.  Stop.
> >
> > So what did you exactly do? Do you have patch on top?
> Yes, I have my own patch on it...
What does that patch exactly contain?

> > > So I can add #ifdef for the
> > > to_phys/to_virt, such as:
> > >
> > > #ifdef __arm__
> > > #define to_phys(x)                 (((paddr_t)(x)+physical_address_offset) & 
> > > 0xffffffff)
> > > #define to_virt(x)                 ((void *)(((x)-physical_address_offset) & 
> > > 0xffffffff))
> > > #ifdef __aarch64__
> > > #define to_phys(x)                 (((paddr_t)(x)-physical_address_offset) & 
> > > ADDR_MASK)
> > > #define to_virt(x)                 ((void *)(((x)+physical_address_offset) & 
> > > ADDR_MASK))
> > > #endif
> > >
> > > What about this solution?
> > That's a NACK from my side. There are strictly no reason to diverge on that
> > between 32-bit and 64-bits. More that if you read my answer to the cover
> > letter, I want to see some cohesion between the 2 ports.
> >
> > This is totally against that idea.
> okay, I will thint this again...
The question here is why do you need to switch + to - for Arm64 compare 
to Arm32?
Cheers,

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel