On Thu, 27 Oct 2011, Jiageng Yu wrote:
> Hi Stefano,
>
> I have some progress in linux based stubdom project. As shown in the
> attached video, I have started the emulated vga device in the linux
> based stubdom.
>
> In a short conclusion, for the linux based stubdom, there are two
> major problems about vga device emulation. The first is the vram
> mapping, which we discussed a lot previously and handled it.
Do you have an updated version of the patch you used?
> Another
> is the vga BIOS mapping (address 0xc0000-0xc8fff of hvm guest).
This is caused by qemu trying to map that memory area in its own address
space, right?
> I found the vga BIOS mapping problem in remap_area_mfn_pte_fn()
> function. The pte_mkspecial() will return invalid value when I try to
> map 0xc0000-0xc8fff into linux based stubdom.
What is exactly the error you are seeing?
> pte_mkspecial()
> ->pte_set_flags()
> ->native_pte_val()
> ->native_make_pte()
>
> According to my test, the root cause of vga BIOS mapping problem is
> native_xxx functions. We could avoid the problem by invoking functions
> defined in paravirt.h instead. The patch is as follows. But I think it
> is not a good way to handle the problem. Maybe you can give me some
> suggestions.
>
> I also found the hard disk
> didn�??�?????�??�????�??�???�??�??�??�?�¢??t work well. I will
> investigate it these days.
>
>
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2639,12 +2640,16 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
> pgtable_t token,
> unsigned long addr, void *data)
> {
> struct remap_data *rmd = data;
> - pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));
> + if((rmd->mfn & 0xfffffff0) == 0xc0){
> + pte_t pte = pfn_pte(rmd->mfn++, rmd->prot);
> + rmd->mmu_update->val = pte_val(pte);
> + }else{
> + pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));
> + rmd->mmu_update->val = pte_val_ma(pte);
> + }
Even if the fix is not the correct one I think I might understand what
the real problem is:
pfn_pte -> xen_make_pte
if (unlikely(pte & _PAGE_IOMAP) &&
(xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
pte = iomap_pte(pte);
} else {
pte &= ~_PAGE_IOMAP;
pte = pte_pfn_to_mfn(pte);
}
considering that in this case xen_initial_domain() returns false and
addr is < ISA_END_ADDRESS (it is a gpfn address), xen_make_pte is going
to threat the mfn as a pfn erroneously.
In your patch you replaced pte_val_ma with pte_val that does the
opposite translation (mfn -> pfn) so the end result is that you get the
original mfn in rmd->mmu_update->val.
The real fix should something along these lines:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3dd53f9..f2fadfc 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -422,7 +422,7 @@ static pteval_t xen_pte_val(pte_t pte)
pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
}
- if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
+ if (pteval & _PAGE_IOMAP)
return pteval;
return pte_mfn_to_pfn(pteval);
@@ -483,8 +483,7 @@ static pte_t xen_make_pte(pteval_t pte)
* mappings are just dummy local mappings to keep other
* parts of the kernel happy.
*/
- if (unlikely(pte & _PAGE_IOMAP) &&
- (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
+ if (unlikely(pte & _PAGE_IOMAP)) {
pte = iomap_pte(pte);
} else {
pte &= ~_PAGE_IOMAP;
---
Could you please confirm whether this patch fixes your problem?
Konrad, do you know if this could have any unintended consequences?
I don't think it can be a problem security wise because Xen is going to
do all the permission checks anyway.
The only problem I can see is if a domU is going to call xen_make_pte
with _PAGE_IOMAP and a pfn->mfn translation is supposed to happen._______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home