On Thursday 09 October 2008 18:12:06 Avi Kivity wrote: > Sheng Yang wrote: > > On Thursday 09 October 2008 17:03:24 Avi Kivity wrote: > >> Sheng Yang wrote: > >>> Hi, Avi > >>> > >>> Here is the latest update of MTRR/PAT support. > >>> > >>> Change from v2: > >>> Discard the using of MSR bitmap, add MSR_IA32_CR_PAT to save/restore, > >>> as well as rebase on latest upstream. > >> > >> Applied all; my comments about shadow can be addressed later. > >> > >> There is also the danger of the guest setting the wrong MTRR type for > >> RAM, thus introducing incompatible memory types (between qemu and the > >> guest). If this is a problem, we should ignore the guest's mtrr (and > >> pat) for RAM and use write-back instead. > > > > Do you mean host(qemu) would access this memory and if we set it to guest > > MTRR, host access would be broken? We would cover this in our shadow MTRR > > patch, for we encountered this in video ram when doing some experiment > > with VGA assignment. > > No, I think that the cpu requires that all accesses to a page be done > using the same memory type. We are allowing the guest to break that, > since qemu mappings will use writeback and guest mapping will use guest > specified memory types.
Yeah, I think the condition I mentioned is a example of yours. But in fact it's difficult to get a optimize value... I think it's possible that qemu may access all memory it owned, if so, no guest mtrr would affect. But how can we tell qemu would access which region of memory? We know it for vram, but any other cases? Seems it's indeed a big potential problem... If we want to do this, maybe we can hack something into host cache consistent check, though it's pretty dirty and got limit usage... -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
