Re: [V10 PATCH 0/4] pvh dom0 patches...

["Roger Pau Monné" <roger.pau@citrix.com>]

On 01/05/14 03:19, Mukesh Rathor wrote:
> On Wed, 30 Apr 2014 11:12:16 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
>> On Wed, 30 Apr 2014 16:11:39 +0200
>> Roger Pau Monné <roger.pau@citrix.com> wrote:
>>
>>> On 30/04/14 03:06, Mukesh Rathor wrote:
>> .....
>>
>>> Hello Mukesh,
>>>
>>> Thanks for the new version, unfortunately when trying to boot
>>> FreeBSD Dom0 with this version I get the following hypervisor crash
>>> (it works fine with previous versions):
>>
>> Aha, Jan, there's the vioapic crash!! Roger, see:
>>
>> http://www.gossamer-threads.com/lists/xen/devel/325784
>>
>> I had seen this few weeks ago, but could not reproduce last week 
>> despite several attempts. You are seeing this in V10 because I dropped
>> the vioapic patch from V9 (included below).
>>
>> BTW, since I'm not able to reproduce this, can you kindly check
>> where the ept violation is coming from? Is that on an io space?
>> Also, our binaries don't match, so can you please confirm it's the 
>> call from:
>>
>> hvm_hap_nested_page_fault():
>>     if ( (p2mt == p2m_mmio_dm) ||
>>          (access_w && (p2mt == p2m_ram_ro)) )
>>     {
>>         put_gfn(p2m->domain, gfn);
>>         if ( !handle_mmio() )   <==========
>>             hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>
>> In which case, what's the p2mt?
>>
> 
> Hey Roger,
> 
> I tried few things, but still could not reproduce. I saw it few weeks
> ago, and I think I misread the code thinking hvm_hap_nested_page_fault
> was calling handle_mmio unconditionally, and quickly came up with
> the vioapic patch for v9. 
> 
> So, can you please try with the vioapic patch. Then two things will
> happen:
> 
>   1. The ept violation is genuine, in which case it will return back
>      successfully to ept_handle_violation which will print the gfn/mfn
>      info for further debug.
>   2. the emulation will be handled, in which case we need to know what
>      was it, mmio_dm or ram_ro, and where it came from in dom0? Both are
>      unexpected.

With the patch applied I can boot fine, no error messages at all. I've
printed the address that's causing the vioapic_range call, it's
0x1073741824, which according to the e820 map passed by Xen falls into a
region marked as valid memory:

SMAP type=01 base=0000000000100000 len=000000003ff6e000

The crash happens because FreeBSD scrubs all valid memory at early boot
when booted with hw.memtest.tests=1.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel