On 17.12.2013 15:35, Fabio Fantoni wrote:
> Il 17/12/2013 15:10, Fabio Fantoni ha scritto:
>> Il 17/12/2013 15:08, Vladimir 'φ-coder/phcoder' Serbinenko ha scritto:
>>>> Thanks.
>>>> Now there is another error, probably introduced by xenfb support:
>>>>
>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest?
>>
>> 64 bit
> 
> I did "git reset --hard" to commit "Remove grub_bios_interrupt on
> coreboot." and then I applied only
> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation."
> commit.
> Now the Sid domU boot correctly, therefore the regression is caused by
> "xenfb" or "xen grants to v1" commit, should I find the exact commit
> that causes that problem or these informations are enough for you?

It's because of vfb. Apparently vfb framebuffer stays mapped as rw even
after vfb shutdown
phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls
/local/domain/54/device/vfb
0 = ""
 backend = "/local/domain/0/backend/vfb/54/0"
 backend-id = "0"
 state = "1"
phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls
/local/domain/0/backend/vfb/54/0
frontend = "/local/domain/54/device/vfb/0"
frontend-id = "54"
online = "1"
state = "2"
domain = "grub"
vnc = "1"
vnclisten = "127.0.0.1"
vncdisplay = "0"
vncunused = "1"
sdl = "0"
opengl = "0"
feature-resize = "1"
hotplug-status = "connected"

When I do "dry vfb": do everything except writing vfb state problem
disappears. So my question would be:
- how can I inspect how backend maps framebuffer pages?
- Why does it map as rw and not ro? It doesn't need to write to framebuffer?
- How do I force it to drop the mapping?