RE: [Xen-devel] guest attempted write to read-only memory page.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Monday, December 22, 2008 6:33 PM
>
>On 22/12/2008 10:12, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> I guess it's caused by 18931 to update rombios to latest bochs
>> version, and some writes to rom area are added outside of disabling
>> rom write access. But I'm not familiar with this part, and thus hope
>> others (Akio?) may take a deeper dive.
>
>Etherboot likes to try to write to its ROM area. That's why I actually
>silenced the warning in __hvm_copy(). I would guess the reason 
>you see this
>issue now is because the accesses are taking the shadow-fault 
>path, which
>means you are no longer emulating real mode? ;-)

I guess it's combined effect from 18891 and 18931. In 18891,
Tim reintroduced vm86 if possible. I didn't change anything and
thus it's interesting that I'm the only one to report this issue. :-)

>
>Possibly we should silence the shadow code too, at least 
>perhaps while in
>real mode or for a certain EIP range.
>

I'm not sure that's the right fix. Why is write access to rom disabled
before rom scan when etherboot is known to have write requirement?

#ifdef HVMASSIST
  call _enable_rom_write_access
  call _clobber_entry_point
  call _copy_e820_table
  call smbios_init
  call _disable_rom_write_access
#endif

  call _init_boot_vectors

  mov  cx, #0xc800  ;; init option roms
  mov  ax, #0xe000
  call rom_scan

Should we move disable action to post rom_scan? If shadow warning
is simply silenced for such case, it seems breaking the purpose of
disable_dom_write_access...

Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel