On Thu, 2015-05-14 at 10:25 +0200, Eric Auger wrote:
> Hi Alex,
> On 05/13/2015 08:32 PM, Alex Williamson wrote:
> > On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
> >> vfio_platform_common now stores a lists of available reset functions.
> >> Two functions are exposed to register/unregister
On Thu, 2015-05-14 at 10:57 +0200, Eric Auger wrote:
> On 05/13/2015 08:33 PM, Alex Williamson wrote:
> > On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
> >> Add the reset function lookup according to the device compat
> >> string. This lookup is added at different places:
> >> - on VFIO_DEVI
On Thu, 2015-05-14 at 11:06 +0200, Eric Auger wrote:
> Alex,
> On 05/13/2015 08:33 PM, Alex Williamson wrote:
> > On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
> >> This patch introduces a module that registers and implements a basic
> >> reset function for the Calxeda xgmac device. This lat
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:05:09PM +0200, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
> > Provide a method to change normal, cacheable memory to non-cacheable.
> > KVM will make use of this to keep emulated device memory regions
> > coherent with the gues
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 Thu, May 14, 2015 at 12:55:49PM +0200, Christoffer Dall wrote:
> On Wed, May 13, 2015 at 01:31:54PM +0200, Andrew Jones wrote:
> > When S1 and S2 memory attributes combine wrt to caching policy,
> > non-cacheable types take precedence. If a guest maps a region as
> > device memory, which KVM use
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 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 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 Fri, Mar 27, 2015 at 01:09:25PM +, Marc Zyngier wrote:
> So far, we configured the world-switch by having a small array
> of pointers to the save and restore functions, depending on the
> GIC used on the platform.
>
> Loading these values each time is a bit silly (they never change),
> and
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 Fri, Mar 27, 2015 at 01:09:24PM +, Marc Zyngier wrote:
> Add a new item to the feature set (ARM64_HAS_SYSREG_GIC_CPUIF)
> to indicate that we have a system register GIC CPU interface
>
> This will help KVM switching to alternative instruction patching.
>
> Reviewed-by: Andre Przywara
> Ac
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 Wed, May 13, 2015 at 01:31:52PM +0200, Andrew Jones wrote:
> Provide a method to change normal, cacheable memory to non-cacheable.
> KVM will make use of this to keep emulated device memory regions
> coherent with the guest.
>
> Signed-off-by: Andrew Jones
Reviewed-by: Christoffer Dall
But
On Wed, May 13, 2015 at 01:31:54PM +0200, Andrew Jones wrote:
> When S1 and S2 memory attributes combine wrt to caching policy,
> non-cacheable types take precedence. If a guest maps a region as
> device memory, which KVM userspace is using to emulate the device
> using normal, cacheable memory, th
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:53PM +0200, Andrew Jones wrote:
> Commit 1050dcda30529 introduced KVM_MEMSLOT_INCOHERENT to flag memory
> regions that may have coherency issues due to mapping host system RAM
> as non-cacheable. This was introduced as a KVM internal flag, but now
> give KVM userspace
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
On 13/05/2015 13:31, Andrew Jones wrote:
> Commit 1050dcda30529 introduced KVM_MEMSLOT_INCOHERENT to flag memory
> regions that may have coherency issues due to mapping host system RAM
> as non-cacheable. This was introduced as a KVM internal flag, but now
> give KVM userspace access to it so tha
Alex,
On 05/13/2015 08:33 PM, Alex Williamson wrote:
> On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
>> This patch introduces a module that registers and implements a basic
>> reset function for the Calxeda xgmac device. This latter basically disables
>> interrupts and stops DMA transfers.
>
On 05/13/2015 08:33 PM, Alex Williamson wrote:
> On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
>> Add the reset function lookup according to the device compat
>> string. This lookup is added at different places:
>> - on VFIO_DEVICE_GET_INFO
>> - on VFIO_DEVICE_RESET
>> - on device release
>>
On 05/13/2015 08:32 PM, Alex Williamson wrote:
> On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
>> A new reset callback is introduced. If this callback is populated,
>> the reset is invoked on device release or upon userspace ioctl. The
>> modality is exposed on VFIO_DEVICE_GET_INFO.
>>
>> Si
On 05/13/2015 08:32 PM, Alex Williamson wrote:
> On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
>> It is needed to introduce a new callback enabling to retrieve the
>> struct device* from the vfio_platform_device. Implementation depends
>> on the underlying device, platform or amba. This will
Hi Alex,
On 05/13/2015 08:32 PM, Alex Williamson wrote:
> On Thu, 2015-05-07 at 16:27 +0200, Eric Auger wrote:
>> vfio_platform_common now stores a lists of available reset functions.
>> Two functions are exposed to register/unregister a reset function. A
>> reset function is paired with a compat s
40 matches
Mail list logo
