Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-15 Thread Michael S. Tsirkin
On Thu, Jun 15, 2017 at 09:07:45AM +0200, Gerd Hoffmann wrote: > Hi, > > > To be specific, what I meant is a bit that tells guest that a > > config space register is available, and lets host find out > > that guest is going to use it. > > > > This to ensure full forward and backward compatibili

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-15 Thread Gerd Hoffmann
Hi, > To be specific, what I meant is a bit that tells guest that a > config space register is available, and lets host find out > that guest is going to use it. > > This to ensure full forward and backward compatibility. > > I agree a fw cfg file for a single bit seems like an overkill, that'

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-14 Thread Michael S. Tsirkin
On Fri, Jun 09, 2017 at 10:01:18PM +0200, Gerd Hoffmann wrote: > On Fri, 2017-06-09 at 13:40 +0200, Paolo Bonzini wrote: > > > > On 08/06/2017 21:55, Michael S. Tsirkin wrote: > > > We don't have room anywhere in PCI config space. Laszlo makes > > > argument > > > why it's safe for this device bas

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-09 Thread Gerd Hoffmann
On Fri, 2017-06-09 at 13:40 +0200, Paolo Bonzini wrote: > > On 08/06/2017 21:55, Michael S. Tsirkin wrote: > > We don't have room anywhere in PCI config space. Laszlo makes > > argument > > why it's safe for this device based on spec but it's anyone's guess > > whether current and future software

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-09 Thread Laszlo Ersek
On 06/09/17 02:19, Michael S. Tsirkin wrote: > On Fri, Jun 09, 2017 at 01:01:54AM +0200, Laszlo Ersek wrote: >> On 06/08/17 21:55, Michael S. Tsirkin wrote: >>> On Thu, Jun 08, 2017 at 09:48:53PM +0200, Gerd Hoffmann wrote: Hi, > I really dislike negotiation being re-invented for ea

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-09 Thread Paolo Bonzini
On 08/06/2017 21:55, Michael S. Tsirkin wrote: > We don't have room anywhere in PCI config space. Laszlo makes argument > why it's safe for this device based on spec but it's anyone's guess > whether current and future software will follow spec. In short, going > anywhere near the emulated devic

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Michael S. Tsirkin
On Fri, Jun 09, 2017 at 01:01:54AM +0200, Laszlo Ersek wrote: > On 06/08/17 21:55, Michael S. Tsirkin wrote: > > On Thu, Jun 08, 2017 at 09:48:53PM +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >>> I really dislike negotiation being re-invented for each device. Do > >>> we > >>> need these tricks?

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Laszlo Ersek
On 06/08/17 21:55, Michael S. Tsirkin wrote: > On Thu, Jun 08, 2017 at 09:48:53PM +0200, Gerd Hoffmann wrote: >> Hi, >> >>> I really dislike negotiation being re-invented for each device. Do >>> we >>> need these tricks? Can we just do fw cfg with standard discovery? >>> This ties in with my pr

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Michael S. Tsirkin
On Thu, Jun 08, 2017 at 09:48:53PM +0200, Gerd Hoffmann wrote: > Hi, > > > I really dislike negotiation being re-invented for each device.  Do > > we > > need these tricks?  Can we just do fw cfg with standard discovery? > > This ties in with my proposal to generalize smi features to > > generic

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Gerd Hoffmann
Hi, > I really dislike negotiation being re-invented for each device.  Do > we > need these tricks?  Can we just do fw cfg with standard discovery? > This ties in with my proposal to generalize smi features to > generic ones. Device properties should be part of the device. We should have done t

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Laszlo Ersek
On 06/08/17 18:34, Paolo Bonzini wrote: > > > On 08/06/2017 18:10, Laszlo Ersek wrote: >> When the guest writes value 0x to this register, the value that can be >> read back is that of "mch.extended-tseg-mbytes" -- unless it remains >> 0x. The guest is required to write 0x first (as o

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Michael S. Tsirkin
On Thu, Jun 08, 2017 at 06:10:13PM +0200, Laszlo Ersek wrote: > The q35 machine type currently lets the guest firmware select a 1MB, 2MB > or 8MB TSEG (basically, SMRAM) size. In edk2/OVMF, we use 8MB, but even > that is not enough when a lot of VCPUs (more than approx. 224) are > configured -- SMR

Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Paolo Bonzini
On 08/06/2017 18:10, Laszlo Ersek wrote: > When the guest writes value 0x to this register, the value that can be > read back is that of "mch.extended-tseg-mbytes" -- unless it remains > 0x. The guest is required to write 0x first (as opposed to a > read-only register) because PCI con

[Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

2017-06-08 Thread Laszlo Ersek
The q35 machine type currently lets the guest firmware select a 1MB, 2MB or 8MB TSEG (basically, SMRAM) size. In edk2/OVMF, we use 8MB, but even that is not enough when a lot of VCPUs (more than approx. 224) are configured -- SMRAM footprint scales largely proportionally with VCPU count. Introduce