On 13/06/13 15:50, Stefano Stabellini wrote:
Keep in mind that if we start the pci hole at 0xe0000000, the number of
cases for which any workarounds are needed is going to be dramatically
decreased to the point that I don't think we need a workaround anymore.
You don't think anyone is going to want to pass through a card with
1GiB+ of RAM?
The algorithm is going to work like this in details:
- the pci hole size is set to 0xfc000000-0xe0000000 = 448MB
- we calculate the total mmio size, if it's bigger than the pci hole we
raise a 64 bit relocation flag
- if the 64 bit relocation is enabled, we relocate above 4G the first
device that is 64-bit capable and has an MMIO size greater or equal to
512MB
- if the pci hole size is now big enough for the remaining devices we
stop the above 4G relocation, otherwise keep relocating devices that are
64 bit capable and have an MMIO size greater or equal to 512MB
- if one or more devices don't fit we print an error and continue (it's
not a critical failure, one device won't be used)
We could have a xenstore flag somewhere that enables the old behaviour
so that people can revert back to qemu-xen-traditional and make the pci
hole below 4G even bigger than 448MB, but I think that keeping the old
behaviour around is going to make the code more difficult to maintain.
We'll only need to do that for one release, until we have a chance to
fix it properly.
Also it's difficult for people to realize that they need the workaround
because hvmloader logs aren't enabled by default and only go to the Xen
serial console.
Well if key people know about it (Pasi, David Techer, &c), and we put it
on the wikis related to VGA pass-through, I think information will get
around.
The value of this workaround pretty low in my view.
Finally it's worth noting that Windows XP is going EOL in less than an
year.
That's 1 year that a configuration with a currently-supported OS won't
work for Xen 4.3 that worked for 4.2. Apart from that, one of the
reasons for doing virtualization in the first place is to be able to run
older, unsupported OSes on current hardware; so "XP isn't important"
doesn't really cut it for me. :-)
I thought that what we had proposed was to have an option in xenstore, that
libxl would set, which would instruct hvmloader whether to expand the MMIO
hole and whether to relocate devices above 64-bit?
I think it's right to have this discussion in public on the mailing
list, rather than behind closed doors.
Also I don't agree on the need for a workaround, as explained above.
I see -- you thought it was a bad idea and so were letting someone else
bring it up -- or maybe hoping no one would remember to bring it up. :-)
(Obviously the decision needs to be made in public, but sometimes having
technical solutions hashed out in a face-to-face meeting is more efficient.)
-George