On 20/05/2015 17:46, Radim Krčmář wrote:
> I am a bit worried about the explosion that would happen if we wanted,
> for example, per-VCPU address spaces
Those would be very expensive. If we were to implement relocatable APIC
base, we would have to do it in a different way than with memslots.
>
2015-05-20 09:07+0200, Paolo Bonzini:
> On 19/05/2015 20:28, Radim Krčmář wrote:
>>> The regular and SMM address spaces are not hierarchical. As soon as you
>>> put a PCI resource underneath SMRAM---which is exactly what happens for
>>> legacy VRAM at 0xa---they can be completely different. N
On 19/05/2015 20:28, Radim Krčmář wrote:
> If I understand your aim correctly, we could go with just one dirty map
> in this way:
> - have a dirty bitmap that covers userspace memory of all slots that
>have enabled dirty log
> - store an offset to this bitmap in those slots
>
> It would be
2015-05-19 18:19+0200, Paolo Bonzini:
> On 19/05/2015 15:32, Radim Krčmář wrote:
> > I'd prefer to decouple address spaces and slots. KVM_GET_DIRTY_LOG
> > could stay the same if we said that a slot can be in multiple address
> > spaces.
>
> Actually, my original plan was a third one. I wanted t
On 19/05/2015 15:32, Radim Krčmář wrote:
> I'd prefer to decouple address spaces and slots. KVM_GET_DIRTY_LOG
> could stay the same if we said that a slot can be in multiple address
> spaces.
Actually, my original plan was a third one. I wanted to have a fixed
number of address spaces, where C
2015-05-18 15:48+0200, Paolo Bonzini:
> +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot"
> +specifies the address space which is being modified. They must be
> +less than the value that KVM_CHECK_EXTENSION returns for the
> +KVM_CAP_MULTI_ADDRESS_SPACE capability.
> +
6 matches
Mail list logo
