[vbox-dev] PDM virtual PCI device bar size

Nikolay Igotti igotti at gmail.com
Thu Apr 25 06:21:51 GMT 2013


  Makes sense, likely uint32_t is used somewhere in size computations, 
and we silently overflow.
We never tested so huge PCI regions, I think. Assert is likely bogus, 
and just manifest we compute
addresses wrong somewhere, and things go wrong later on.

  If you could figure out where it happens - guess VBox devs would 
accept your change.
Generally ICH9 code shall be easier to understand and modify, although 
problem could be in generic PDM code.

   Nikolay

On 04/24/2013 05:47 PM, José Massada wrote:
> I managed to get it to call my callbacks.
> Calling PDMDevHlpMMIORegister with the phys address and the full size 
> does not work. By calling PDMDevHlpMMIORegister with smaller sizes 
> (and the correct phys address) it works.
>
> Calling PDMDevHlpMMIORegister with phys addr 0x40000000 and 
> size 0x20000000 fails.
> Calling PDMDevHlpMMIORegister 4 times with phys addr 
> 0x40000000, 0x48000000, 0x50000000 and 0x58000000, and size 0x8000000 
> works.
>
> Jose
>
>
> On Wed, Apr 24, 2013 at 10:30 AM, José Massada <jose.massada at gmail.com 
> <mailto:jose.massada at gmail.com>> wrote:
>
>     Not sure if relevant but I got the following errors on the log
>     (the machine still loads) when using the ICH9 chipset:
>
>     00:00:11.500658 VMSetError:
>     /home/vbox/vbox-4.2.10/src/VBox/VMM/VMMR3/PGMPhys.cpp(4502) int
>     pgmPhysFreePage(VM*, GMMFREEPAGESREQ*, uint32_t*, PGMPAGE*,
>     RTGCPHYS); rc=VERR_PGM_PHYS_NOT_RAM
>     00:00:11.500676 VMSetError: GCPhys=0000000020001000 type=6
>     00:00:11.500723 AssertLogRel
>     /home/vbox/vbox-4.2.10/src/VBox/VMM/VMMR3/PGMPhys.cpp(911) int
>     pgmR3PhysFreePageRange(VM*, PGMRAMRANGE*, RTGCPHYS, RTGCPHYS,
>     uint8_t): RT_SUCCESS_NP(rc)
>     00:00:11.501156 VERR_PGM_PHYS_NOT_RAM (-1639) - Trying to free a
>     page that isn't RAM.
>     00:00:11.581464 AssertLogRel
>     /home/vbox/vbox-4.2.10/src/VBox/VMM/VMMR3/PGMPhys.cpp(2248) int
>     PGMR3PhysMMIORegister(VM*, RTGCPHYS, RTGCPHYS, int (*)(VM*,
>     RTGCPHYS, void*, void*, size_t, PGMACCESSTYPE, void*), void*,
>     RTHCUINTPTR, RTR0PTR, RTRCPTR, RTRCPTR, const char*):
>     RT_SUCCESS_NP(rc)
>     00:00:11.581495 cbRamRange=2097280
>
>
>     And when using PIIX3, I only get this next one:
>
>     00:00:11.926143 AssertLogRel
>     /home/vbox/vbox-4.2.10/src/VBox/VMM/VMMR3/PGMPhys.cpp(2248) int
>     PGMR3PhysMMIORegister(VM*, RTGCPHYS, RTGCPHYS, int (*)(VM*,
>     RTGCPHYS, void*, void*, size_t, PGMACCESSTYPE, void*), void*,
>     RTHCUINTPTR, RTR0PTR, RTRCPTR, RTRCPTR, const char*):
>     RT_SUCCESS_NP(rc)
>     00:00:11.926178 cbRamRange=2097280
>
>     Jose
>
>
>     On Wed, Apr 24, 2013 at 8:18 AM, José Massada
>     <jose.massada at gmail.com <mailto:jose.massada at gmail.com>> wrote:
>
>         I tried both but lately I've been testing with ICH9. Same
>         behaviour.
>
>         Jose
>
>         On 24/04/2013, at 08:08, Nikolay Igotti <igotti at gmail.com
>         <mailto:igotti at gmail.com>> wrote:
>
>>          Which chipset you are using? ICH9 generally shall be better
>>         suited for your needs, due to recent
>>         PCI features support.
>>
>>           Nikolay
>>
>>         23.04.2013 18:25, José Massada пишет:
>>>         Hi all,
>>>
>>>         I'm working on a PDM virtual PCI device module and I need to
>>>         have a bar size of 512MB.
>>>         This particular PCI device uses bar 0 and 1 for register
>>>         blocks (64KB each) and bar 2 for memory (this one I need to
>>>         be 512MB or even bigger).
>>>
>>>         Registering the memory bar using the MMIO2 functions fails
>>>         when the size is bigger than 256MB (hard coded limit in the
>>>         allocation function) so I tried registering using MMIO. It
>>>         seems to work but my read and write callbacks never get
>>>         called (bar 0 and 1 also use MMIO and their callbacks always
>>>         get called). I tried decreasing the bar 2 size and the
>>>         callbacks got called.
>>>
>>>         Is this even possible without modifying VBox source code?
>>>         What am I missing?
>>>
>>>         Thanks,
>>>         Jose
>>>
>>>
>>>         _______________________________________________
>>>         vbox-dev mailing list
>>>         vbox-dev at virtualbox.org  <mailto:vbox-dev at virtualbox.org>
>>>         https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130425/dce17390/attachment.html>


More information about the vbox-dev mailing list