On Wed, May 29, 2019 at 06:05:41PM -0400, Michael S. Tsirkin wrote:
> On Tue, May 28, 2019 at 10:43:31PM +0200, Gerd Hoffmann wrote:
> > This patch changes the handling of the mmconfig area. Thanks to the
> > pci(e) expander devices we already have the logic to exclude address
> > ranges from PCI0
On 06/03/19 16:24, Gerd Hoffmann wrote:
> Hi,
>
>> One question: are we sure all guest OSes we care about can deal with
>> discontiguous 32-bit PCI MMIO aperture(s)? Personally, I've got no clue.
>> Is a "naïve" OS imaginable that looks only at the first suitable range
>> in the _CRS?
>
> Well
Hi,
> One question: are we sure all guest OSes we care about can deal with
> discontiguous 32-bit PCI MMIO aperture(s)? Personally, I've got no clue.
> Is a "naïve" OS imaginable that looks only at the first suitable range
> in the _CRS?
Well, I know there is physical hardware doing the same t
On 05/28/19 22:43, Gerd Hoffmann wrote:
> This patch changes the handling of the mmconfig area. Thanks to the
> pci(e) expander devices we already have the logic to exclude address
> ranges from PCI0._CRS. We can simply add the mmconfig address range
> to the list get it excluded as well.
>
> Wi
On Tue, 28 May 2019 22:43:31 +0200
Gerd Hoffmann wrote:
> This patch changes the handling of the mmconfig area. Thanks to the
> pci(e) expander devices we already have the logic to exclude address
> ranges from PCI0._CRS. We can simply add the mmconfig address range
> to the list get it exclude
On Tue, May 28, 2019 at 10:43:31PM +0200, Gerd Hoffmann wrote:
> This patch changes the handling of the mmconfig area. Thanks to the
> pci(e) expander devices we already have the logic to exclude address
> ranges from PCI0._CRS. We can simply add the mmconfig address range
> to the list get it ex
On Wed, May 29, 2019 at 01:16:52PM +0200, Igor Mammedov wrote:
> On Tue, 28 May 2019 22:43:31 +0200
> Gerd Hoffmann wrote:
>
> > This patch changes the handling of the mmconfig area. Thanks to the
> > pci(e) expander devices we already have the logic to exclude address
> > ranges from PCI0._CRS.
On Tue, 28 May 2019 22:43:31 +0200
Gerd Hoffmann wrote:
> This patch changes the handling of the mmconfig area. Thanks to the
> pci(e) expander devices we already have the logic to exclude address
> ranges from PCI0._CRS. We can simply add the mmconfig address range
> to the list get it exclude
On 29/05/19 07:11, Marcel Apfelbaum wrote:
> I am not saying is a "big" issue since it will probably not affect the
> guests at all.
> Upgrading QEMU will look like a firmware update or something.
Yeah, this happens all the time. This kind of bugfix is generally not
versioned.
Paolo
Hi Gerd,
On 5/29/19 8:01 AM, Gerd Hoffmann wrote:
On Wed, May 29, 2019 at 07:48:03AM +0300, Marcel Apfelbaum wrote:
Hi Gerd,
On 5/28/19 11:43 PM, Gerd Hoffmann wrote:
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to excl
On Wed, May 29, 2019 at 07:48:03AM +0300, Marcel Apfelbaum wrote:
> Hi Gerd,
>
> On 5/28/19 11:43 PM, Gerd Hoffmann wrote:
> > This patch changes the handling of the mmconfig area. Thanks to the
> > pci(e) expander devices we already have the logic to exclude address
> > ranges from PCI0._CRS. W
Hi Gerd,
On 5/28/19 11:43 PM, Gerd Hoffmann wrote:
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
With that in place we can go with a fixed pci hole whi
13 matches
Mail list logo
