<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:#002060;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#002060">Hi experts,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">I have a virtual device model plugged into VirtualBox 5.1.24 OSE via PDM, and I am seeing a problem with the ICH9 fake BIOS support of prefetch space.  Or maybe that’s not the right way to put it.  Let me explain
 what I’m trying to do and then my problem.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">I actually have two different virtual device models.  The first has a PCIe switch plugged into host bus at 0:28:0, with secondary bus connected to an endpoint at 3:0:0.  The endpoint has two 64-bit BAR pairs,
 both with the prefetch flag set, but they’re small.  The fake BIOS enumerates, sets up the endpoint BARs and the bridge’s prefetch-base/limit registers which I then use to register the address range with PDMDevHlpMMIORegister(). This model works well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">The second model has a PCI/PCIe switch inserted, so a bridge at 0:28:0, another at 3:0:0, another at 4:0:0, and the endpoint at 5:0:0.    This endpoint also has two 64-bit BAR pairs, both with the prefetch flag
 set, one big one small.  When I try to register the address ranges with PDMDevHlpMMIORegister() it returns VERR_MM_HYPER_NO_MEMORY.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">First question is whether this is indeed the right way to get those address redirected through PDM to my model?  It seems to lead to memory allocation, which I don’t need since the memory is modeled in my virtual
 device.  I just need to take care of accesses within the range assigned by the fake BIOS.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Second question is whether someone can elaborate on this comment in ich9pciBiosInitDeviceBARs()? 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">        /* Hack: since this PCI init code cannot handle prefetchable BARs on<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * anything besides the primary bus, it's for now the best solution<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * to leave such BARs uninitialized and keep memory transactions<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * disabled. The OS will hopefully be clever enough to fix this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * Prefetchable BARs are the only ones which can be truly big (and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * are almost always 64-bit BARs). The non-prefetchable ones will not<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">         * cause running out of space in the PCI memory hole. */<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">It is programming the prefetch-base/limit registers of all the bridges, so in what way can the PCI init code not “handle prefetchable BARs on anything besides the primary bus”?  In what way can we hope the OS
 will be “clever enough to fix this”?  The lspci –vv command shows valid address ranges, based on the base/limit registers, but the BARs won’t respond if accessed.  And is there an issue with PCI addresses above 4G?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">I will keep digging and learning, because I don’t yet understand the connection between this and VERR_MM_HYPER_NO_MEMORY — which I believe comes from mmHyperAllocInternal() — but some insight would be helpful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060">//  RicV<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
</div>
</body>
</html>