On Tue, Sep 23, 2008 at 10:31:30AM +0300, Avi Kivity wrote: > Glauber Costa wrote: >> On Sat, Sep 20, 2008 at 11:38:22AM -0700, Avi Kivity wrote: >> >>> Glauber Costa wrote: >>> >>>> By analysing phys_offset, we know whether a region is an mmio region >>>> or not. If it is, register it as so. We don't reuse the same slot >>>> infrastructure already existant, because there is a relationship between >>>> the slot number for kvm the kernel module, and the index in the slots >>>> vector >>>> for libkvm. However, we can do best in the future and use only a single >>>> data structure >>>> for both. >>>> >>>> >>> Why is kvm interested in emulated mmio regions, at all? >>> >> We don't need to. If the region is an mmio region, we do nothing (well, >> later on, I'm >> coalescing the accesses). > > Oh no you don't. > >> But still, we need to keep track. Otherwise, qemu can (and it will) >> try to register subsets of that memory, but without any indication that this >> is part of an mmio region >> > > Why do we care? > >> Our algorithm will fail in this case, since we will then register a memory >> area we should have left blank. >> So think of mmio in this case as a "please leave it blank". >> > > Confused. If qemu knows about the mmio regions, surely it won't try to > overlay them with RAM?
Oh, you're right. I thought a lot of cases of subregions being registered lacked the proper MMIO flags. But I think I was confused by an earlier issue. It'll get even simpler! > > -- > error compiling committee.c: too many arguments to function > -- 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
