On Tue, May 24, 2011 at 09:47:57PM -0600, Alex Williamson wrote:
> On Thu, 2011-05-05 at 18:21 +0300, Michael S. Tsirkin wrote:
> > On Thu, May 05, 2011 at 08:21:06AM -0600, Alex Williamson wrote:
> > > On Thu, 2011-05-05 at 16:21 +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 03, 2011 at 12:
On Thu, 2011-05-05 at 18:21 +0300, Michael S. Tsirkin wrote:
> On Thu, May 05, 2011 at 08:21:06AM -0600, Alex Williamson wrote:
> > On Thu, 2011-05-05 at 16:21 +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 03, 2011 at 12:36:58PM -0600, Alex Williamson wrote:
> > > > When a phys memory client r
On Thu, May 05, 2011 at 05:40:19PM +0200, Jes Sorensen wrote:
> On 05/05/11 17:38, Michael S. Tsirkin wrote:
> > On Thu, May 05, 2011 at 05:36:04PM +0200, Jes Sorensen wrote:
> >> > On 05/05/11 17:18, Michael S. Tsirkin wrote:
> > > >> > A memory size can obviously not be bigger than the maximu
On 05/05/11 17:38, Michael S. Tsirkin wrote:
> On Thu, May 05, 2011 at 05:36:04PM +0200, Jes Sorensen wrote:
>> > On 05/05/11 17:18, Michael S. Tsirkin wrote:
> > >> > A memory size can obviously not be bigger than the maximum physical
> > >> > address, so I find it really hard to see how t
On Thu, May 05, 2011 at 05:36:04PM +0200, Jes Sorensen wrote:
> On 05/05/11 17:18, Michael S. Tsirkin wrote:
> >> > A memory size can obviously not be bigger than the maximum physical
> >> > address, so I find it really hard to see how this could overflow.
> > For example, a 4G size does not fit in
On 05/05/11 17:18, Michael S. Tsirkin wrote:
>> > A memory size can obviously not be bigger than the maximum physical
>> > address, so I find it really hard to see how this could overflow.
> For example, a 4G size does not fit in 32 bits.
That is the only corner case - you can handle that by -1 if
On Thu, May 05, 2011 at 08:21:06AM -0600, Alex Williamson wrote:
> On Thu, 2011-05-05 at 16:21 +0300, Michael S. Tsirkin wrote:
> > On Tue, May 03, 2011 at 12:36:58PM -0600, Alex Williamson wrote:
> > > When a phys memory client registers and we play catchup by walking
> > > the page tables, we can
On Thu, May 05, 2011 at 04:30:57PM +0200, Jes Sorensen wrote:
> On 05/05/11 16:21, Alex Williamson wrote:
> >> > A bit worried that ram_addr_t size might thinkably overflow
> >> > (it's just a long, could be a 4G ram). Break it out when it fills up?
> > struct CPUPhysMemoryClient {
> > void (*s
On 05/05/11 16:21, Alex Williamson wrote:
>> > A bit worried that ram_addr_t size might thinkably overflow
>> > (it's just a long, could be a 4G ram). Break it out when it fills up?
> struct CPUPhysMemoryClient {
> void (*set_memory)(struct CPUPhysMemoryClient *client,
>
On Thu, 2011-05-05 at 16:21 +0300, Michael S. Tsirkin wrote:
> On Tue, May 03, 2011 at 12:36:58PM -0600, Alex Williamson wrote:
> > When a phys memory client registers and we play catchup by walking
> > the page tables, we can make a huge improvement in the number of
> > times the set_memory callba
On Tue, May 03, 2011 at 12:36:58PM -0600, Alex Williamson wrote:
> When a phys memory client registers and we play catchup by walking
> the page tables, we can make a huge improvement in the number of
> times the set_memory callback is called by batching contiguous
> pages together. With a 4G gues
When a phys memory client registers and we play catchup by walking
the page tables, we can make a huge improvement in the number of
times the set_memory callback is called by batching contiguous
pages together. With a 4G guest, this reduces the number of callbacks
at registration from 1048866 to 2
12 matches
Mail list logo