On Thu, Jul 29, 2021 at 3:08 AM Philippe Mathieu-Daudé
wrote:
> Michael, if describing the issue in the revert is too complex, could you
> include a link to this thread in the revert description?
> (Message-Id: <20210724185234.ga2265...@roeck-us.net> or
> https://www.mail-archive.com/qemu-devel@n
On Mon, Jul 26, 2021 at 09:22:19PM -0700, Guenter Roeck wrote:
> On 7/26/21 2:31 PM, Bjorn Helgaas wrote:
> > [+cc linux-pci]
> >
> > On Mon, Jul 26, 2021 at 04:16:29PM -0500, Bjorn Helgaas wrote:
> > > On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
[+cc linux-pci]
On Mon, Jul 26, 2021 at 04:16:29PM -0500, Bjorn Helgaas wrote:
> On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> > On Mon, 26 Jul 2021 at 11:08, Philippe Mathieu-Daudé
> > wrote:
> > > On 7/26/21 12:56 AM, Guenter Roeck wrote:
&g
On Mon, Jul 26, 2021 at 06:00:57PM +0200, Ard Biesheuvel wrote:
> (cc Bjorn)
>
> On Mon, 26 Jul 2021 at 11:08, Philippe Mathieu-Daudé
> wrote:
> > On 7/26/21 12:56 AM, Guenter Roeck wrote:
> > > On 7/25/21 3:14 PM, Michael S. Tsirkin wrote:
> > >> On Sat, Jul 24, 2021 at 11:52:34AM -0700, Guente
[+cc Michael, Jesse, David, qemu-devel]
On Wed, Jan 15, 2014 at 8:58 PM, wrote:
> I suggest you should not break the PCI specification, as a developer of
> proprietary
> hypervisor, but I think your patch is no problem.
> Your PCI structure is specialized structure for your virtual machine.
> M
[+cc Jesse, David]
On Wed, Jan 15, 2014 at 12:19 PM, Sander Eikelenboom
wrote:
>>> >> I understood there is no bridge for a VGA device in your virtual
>>> >> machine.
>>> >> Your emulator for the bridge control register is odd.
>>>
>>> > That seems beside the point as there's no
On Mon, May 20, 2013 at 12:32 PM, Michael S. Tsirkin wrote:
> On Mon, May 20, 2013 at 11:09:56AM -0600, Bjorn Helgaas wrote:
>> Indicate ASPM L0s and L1 support in Link Capabilities and make the ASPM
>> bits in Link Control writable. These Link Control bits don't do anyt
On Sun, May 19, 2013 at 5:54 AM, Michael S. Tsirkin wrote:
> On Wed, May 15, 2013 at 04:33:08PM -0600, Bjorn Helgaas wrote:
>> Indicate ASPM L0s and L1 support in Link Capabilities and make the ASPM
>> bits in Link Control writable. These Link Control bits don't do anyt
Indicate ASPM L0s and L1 support in Link Capabilities and make the ASPM
bits in Link Control writable. These Link Control bits don't do anything
in qemu, but having them writable means the BIOS or OS can write them as
on real hardware.
Signed-off-by: Bjorn Helgaas
---
hw/pci/p
Linux actually doesn't have definitions for the individual L0s and L1 bits
in Link Capabilities, but if/when it does, it will use these names, which
follow the Link Control naming pattern.
Signed-off-by: Bjorn Helgaas
---
hw/pci/pcie.c |2 +-
include/hw/pci/pcie_regs.h |
Indicate ASPM L0s and L1 support in Link Capabilities and make the ASPM
bits in Link Control writable. These Link Control bits don't do anything
in qemu, but having them writable means the BIOS or OS can write them as
on real hardware.
Signed-off-by: Bjorn Helgaas
---
hw/pci/p
On Mon, Nov 26, 2012 at 11:46 PM, Gleb Natapov wrote:
> On Mon, Nov 26, 2012 at 09:46:12PM -0200, Marcelo Tosatti wrote:
>> On Tue, Nov 20, 2012 at 02:09:46PM +, Pandarathil, Vijaymohan R wrote:
>> >
>> >
>> > > -Original Message-
>> > > From: Stefan Hajnoczi [mailto:stefa...@gmail.com
On Wed, May 23, 2012 at 1:03 AM, Amos Kong wrote:
> On Wed, May 23, 2012 at 1:29 PM, Yinghai Lu wrote:
>> On Tue, May 22, 2012 at 10:15 PM, Amos Kong wrote:
>>> Attached the v7, test passed.
>>
>> would be better to have break...
>
> Yeah. Otherwise, it will delete from the last function.
> Att
with Windows guests. This patch
makes it also work in Linux guests.
[bhelgaas: restructure loop iteration, pull out of slot->funcs loop]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=43219
Signed-off-by: Amos Kong
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/acpiphp_glue.c |
From: Amos Kong
Previously, we acquired two references to function 0, but only released
one.
[bhelgaas: split this out from "remove all functions" fix]
Signed-off-by: Amos Kong
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/acpiphp_glue.c |1 +
1 files changed, 1 insert
Here's my proposal for fixing this problem.
I split out the pci_dev_put() for function 0 because it looks to me
like that is actually a separate issue -- it looks like we leaked
that reference even for single-function devices.
I restructured the iteration over bus->devices to make it read a bit
m
> I tried to work through some examples to develop some intuition about this:
Sorry, gmail inserted line breaks that ruined this picture. Here's a
URL for it:
http://www.asciiflow.com/#3736558963405980039
On Mon, May 14, 2012 at 4:49 PM, Alex Williamson
wrote:
> On Mon, 2012-05-14 at 16:02 -0600, Bjorn Helgaas wrote:
>> On Fri, May 11, 2012 at 4:56 PM, Alex Williamson
>> wrote:
>> > In a PCIe environment, transactions aren't always required to
>> > reach the
On Fri, May 11, 2012 at 8:00 AM, Jiang Liu wrote:
> On 05/11/2012 08:24 AM, Amos Kong wrote:
>> On 05/11/2012 07:54 AM, Amos Kong wrote:
>>> On 05/11/2012 02:55 AM, Michael S. Tsirkin wrote:
On Fri, May 11, 2012 at 01:09:13AM +0800, Jiang Liu wrote:
> On 05/10/2012 11:44 PM, Amos Kong wro
On Fri, May 11, 2012 at 4:56 PM, Alex Williamson
wrote:
> In a PCIe environment, transactions aren't always required to
> reach the root bus before being re-routed. Peer-to-peer DMA
> may actually not be seen by the IOMMU in these cases. For
> IOMMU groups, we want to provide IOMMU drivers a way
r_write_config_dword(struct pci_dev *dev, int where, u32
> val);
If you repost this, can you remove the externs when you move these
declarations? I know the file's currently a random mix, but we might
as well make a tiny improvement.
Looks fine to me otherwise, and if you don't h
21 matches
Mail list logo
