On Thu, May 14, 2015 at 03:36:37PM +0200, Andrew Jones wrote:
> On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote:
> > On 14 May 2015 at 14:03, Andrew Jones wrote:
> > > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> > >> On 14 May 2015 at 11:31, Andrew Jones wrote:
On 14 May 2015 at 16:41, Michael S. Tsirkin wrote:
> On Thu, May 14, 2015 at 04:19:23PM +0200, Laszlo Ersek wrote:
>> On 05/14/15 15:48, Michael S. Tsirkin wrote:
>> > On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
>> >> On 05/14/15 15:00, Andrew Jones wrote:
>> >>> On Thu, May 14,
On Thu, May 14, 2015 at 04:19:23PM +0200, Laszlo Ersek wrote:
> On 05/14/15 15:48, Michael S. Tsirkin wrote:
> > On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
> >> On 05/14/15 15:00, Andrew Jones wrote:
> >>> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> On 1
On 05/14/15 15:48, Michael S. Tsirkin wrote:
> On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
>> On 05/14/15 15:00, Andrew Jones wrote:
>>> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> Well, PCI BARs are gene
On 05/14/15 14:34, Christoffer Dall wrote:
> On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 14/05/2015 14:24, Christoffer Dall wrote:
>>> On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
On 14/05/2015 14:00, Christoffer Dall wrote:
> So,
On Thu, May 14, 2015 at 03:32:10PM +0200, Laszlo Ersek wrote:
> On 05/14/15 15:00, Andrew Jones wrote:
> > On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> >> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> >>> Well, PCI BARs are generally MMIO resources, and hence should not be
>
On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> > Well, PCI BARs are generally MMIO resources, and hence should not be cached.
> >
> > As an optimization, OS drivers can mark them as cacheable or
> > write-combining or something like
On Thu, May 14, 2015 at 02:11:59PM +0100, Peter Maydell wrote:
> On 14 May 2015 at 14:03, Andrew Jones wrote:
> > On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> >> On 14 May 2015 at 11:31, Andrew Jones wrote:
> >> > Forgot to (4): switch from setting userspace's mapping to
> >>
On 05/14/15 15:11, Peter Maydell wrote:
> On 14 May 2015 at 14:03, Andrew Jones wrote:
>> On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
>>> On 14 May 2015 at 11:31, Andrew Jones wrote:
Forgot to (4): switch from setting userspace's mapping to
device memory to normal, no
On 05/14/15 15:00, Andrew Jones wrote:
> On Thu, May 14, 2015 at 01:38:11PM +0100, Peter Maydell wrote:
>> On 14 May 2015 at 13:28, Paolo Bonzini wrote:
>>> Well, PCI BARs are generally MMIO resources, and hence should not be cached.
>>>
>>> As an optimization, OS drivers can mark them as cacheabl
On 14 May 2015 at 14:03, Andrew Jones wrote:
> On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
>> On 14 May 2015 at 11:31, Andrew Jones wrote:
>> > Forgot to (4): switch from setting userspace's mapping to
>> > device memory to normal, non-cacheable. Using device memory
>> > caused
On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
> On 14 May 2015 at 11:31, Andrew Jones wrote:
> > Forgot to (4): switch from setting userspace's mapping to
> > device memory to normal, non-cacheable. Using device memory
> > caused a problem that Alex Graf found, and Peter Maydell s
On 14 May 2015 at 13:28, Paolo Bonzini wrote:
> Well, PCI BARs are generally MMIO resources, and hence should not be cached.
>
> As an optimization, OS drivers can mark them as cacheable or
> write-combining or something like that, but in general it's a safe
> default to leave them uncached---one
On Thu, May 14, 2015 at 02:28:49PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 14:24, Christoffer Dall wrote:
> > On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/05/2015 14:00, Christoffer Dall wrote:
> >>> So, getting back to my original question. Is the
On 14/05/2015 14:24, Christoffer Dall wrote:
> On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 14/05/2015 14:00, Christoffer Dall wrote:
>>> So, getting back to my original question. Is the point then that UEFI
>>> must assume (from ACPI/DT) the cache-coherency propert
On Thu, May 14, 2015 at 02:08:49PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 14:00, Christoffer Dall wrote:
> > So, getting back to my original question. Is the point then that UEFI
> > must assume (from ACPI/DT) the cache-coherency properties of the PCI
> > controller which exists in hard
On 14/05/2015 14:00, Christoffer Dall wrote:
> So, getting back to my original question. Is the point then that UEFI
> must assume (from ACPI/DT) the cache-coherency properties of the PCI
> controller which exists in hardware on the system you're running on,
> even for the virtual PCI bus becaus
On Thu, May 14, 2015 at 01:38:38PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:36, Christoffer Dall wrote:
> > > > > (It's probably worth looking at the documentation in the first hunk
> > > > > too,
> > > > > under the commit message.)
> > > >
> > > > Why is this a hack/unintuitive? Is
On 14/05/2015 13:36, Christoffer Dall wrote:
> > > > (It's probably worth looking at the documentation in the first hunk too,
> > > > under the commit message.)
> > >
> > > Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
> > > not simply that MMIO regions are coherent?
> >
On Thu, May 14, 2015 at 01:31:03PM +0200, Paolo Bonzini wrote:
>
>
> On 14/05/2015 13:29, Christoffer Dall wrote:
> > > (It's probably worth looking at the documentation in the first hunk too,
> > > under the commit message.)
> >
> > Why is this a hack/unintuitive? Is the semantics of the QEMU
On 14/05/2015 13:29, Christoffer Dall wrote:
> > (It's probably worth looking at the documentation in the first hunk too,
> > under the commit message.)
>
> Why is this a hack/unintuitive? Is the semantics of the QEMU PCI bus
> not simply that MMIO regions are coherent?
Only until device assig
On Thu, May 14, 2015 at 01:09:34PM +0200, Laszlo Ersek wrote:
> On 05/14/15 12:30, Christoffer Dall wrote:
> > On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
> >> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
> >> needed by ARM. This flag informs KVM that the given m
On 05/14/15 12:30, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
>> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
>> needed by ARM. This flag informs KVM that the given memory region
>> is typically mapped by the guest as non-cacheable. KVM
On 14 May 2015 at 11:31, Andrew Jones wrote:
> Forgot to (4): switch from setting userspace's mapping to
> device memory to normal, non-cacheable. Using device memory
> caused a problem that Alex Graf found, and Peter Maydell suggested
> using normal, non-cacheable instead.
Did you check that non
On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
> needed by ARM. This flag informs KVM that the given memory region
> is typically mapped by the guest as non-cacheable. KVM for ARM
> then ensures that that memory is inde
On Wed, May 13, 2015 at 01:31:51PM +0200, Andrew Jones wrote:
> Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
> needed by ARM. This flag informs KVM that the given memory region
> is typically mapped by the guest as non-cacheable. KVM for ARM
> then ensures that that memory is inde
Introduce a new memory region flag, KVM_MEM_UNCACHED, which is
needed by ARM. This flag informs KVM that the given memory region
is typically mapped by the guest as non-cacheable. KVM for ARM
then ensures that that memory is indeed mapped non-cacheable by
the guest, and also remaps that region as n
27 matches
Mail list logo
