On 06/20/2016 01:42 PM, Igor Mammedov wrote:
On Sun, 19 Jun 2016 19:13:17 +0300
Marcel Apfelbaum wrote:
On 06/17/2016 07:07 PM, Laszlo Ersek wrote:
On 06/17/16 11:52, Igor Mammedov wrote:
On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann wrote:
On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzi
On Sun, 19 Jun 2016 19:13:17 +0300
Marcel Apfelbaum wrote:
> On 06/17/2016 07:07 PM, Laszlo Ersek wrote:
> > On 06/17/16 11:52, Igor Mammedov wrote:
> >> On Fri, 17 Jun 2016 11:17:54 +0200
> >> Gerd Hoffmann wrote:
> >>
> >>> On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
>
> O
On 19/06/2016 05:36, Michael S. Tsirkin wrote:
> > Making the guest's phys-bits larger than host-phys-bits would be okay if
> > you reserve the area in the e820 and assume the guest doesn't touch it.
>
> How would it touch it if there's no RAM there?
> PCI BARs is the only thing that comes to min
On 06/17/2016 07:07 PM, Laszlo Ersek wrote:
On 06/17/16 11:52, Igor Mammedov wrote:
On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann wrote:
On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:
Larger is a problem if the guest tries to ma
On Fri, Jun 17, 2016 at 03:38:53PM +0200, Paolo Bonzini wrote:
> Making the guest's phys-bits larger than host-phys-bits would be okay if
> you reserve the area in the e820 and assume the guest doesn't touch it.
How would it touch it if there's no RAM there?
PCI BARs is the only thing that comes t
On 06/17/16 13:20, Gerd Hoffmann wrote:
> Hi,
>
>>> Not sure whenever qemu adds some extra space for hotplug to the 64bit
>>> hole and if so how it calculates the size then. But the guest os should
>>> stick to those ranges when configuring hotplugged devices.
>
>> currently firmware would ass
On 06/17/16 11:52, Igor Mammedov wrote:
> On Fri, 17 Jun 2016 11:17:54 +0200
> Gerd Hoffmann wrote:
>
>> On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
>>>
>>> On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:
Larger is a problem if the guest tries to map something to a high
On Fri, Jun 17, 2016 at 05:28:03PM +0200, Paolo Bonzini wrote:
> On 17/06/2016 17:19, Eduardo Habkost wrote:
> > > > So, what happens if the guest play tricks in bits 40-45 when QEMU
> > > > sets the limit to 40 but we are running in a 46-bit host? Is it
> > > > really a problem? I assumed it would
On Fri, Jun 17, 2016 at 03:38:53PM +0200, Paolo Bonzini wrote:
>
>
> On 17/06/2016 15:18, Eduardo Habkost wrote:
> > On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
> >> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> >>> On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. Davi
On 17/06/2016 17:19, Eduardo Habkost wrote:
> > > So, what happens if the guest play tricks in bits 40-45 when QEMU
> > > sets the limit to 40 but we are running in a 46-bit host? Is it
> > > really a problem? I assumed it would be safe.
> >
> > The guest expects a "reserved bit set" page fault,
On 06/17/2016 04:18 PM, Eduardo Habkost wrote:
On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
* Eduardo Habkost (ehabk...@redhat.com) wrote:
On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git) wrote:
From: "Dr. David Alan Gilbert"
Currently QEMU se
On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > Currently QEMU sets the x86 number of ph
On 17/06/2016 15:18, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (ehabk...@redhat.com) wrote:
>>> On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git)
>>> wrote:
From: "Dr. David Alan Gilbert"
Hi,
> > Not sure whenever qemu adds some extra space for hotplug to the 64bit
> > hole and if so how it calculates the size then. But the guest os should
> > stick to those ranges when configuring hotplugged devices.
> currently firmware would assign 64-bit BARs after reserved-memory-end
> (no
On 17/06/2016 11:37, Dr. David Alan Gilbert wrote:
>>> The existing 40-bit default looks like a problem for 36-bit
>>> > > systems. Do you know what kind of systems have 36 bits only? Only
>>> > > old ones, or recent ones too? If only old ones, how old?
>> >
>> > My Sandy Bridge (~2.5 year old)
On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann wrote:
> On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
> >
> > On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:
> > > Larger is a problem if the guest tries to map something to a high
> > > address that's not addressable.
> >
> > R
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> > The existing 40-bit default looks like a problem for 36-bit
> > systems. Do you know what kind of syst
On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
>
> On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:
> > Larger is a problem if the guest tries to map something to a high
> > address that's not addressable.
>
> Right. It's not a problem for most emulated PCI devices (it would be a
> pro
On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:
> Larger is a problem if the guest tries to map something to a high
> address that's not addressable.
Right. It's not a problem for most emulated PCI devices (it would be a
problem for those that have large RAM BARs, but even our emulated video
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Currently QEMU sets the x86 number of physical address bits to the
> > magic number 40. This is only correct on some small AMD
On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Currently QEMU sets the x86 number of physical address bits to the
> magic number 40. This is only correct on some small AMD systems;
> Intel systems tend to have 36, 39, 46 bits, a
On Thu, Jun 16, 2016 at 07:26:01PM +0200, Paolo Bonzini wrote:
>
>
> On 16/06/2016 19:12, Dr. David Alan Gilbert (git) wrote:
> > if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
> > -/* 64 bit processor */
> > -/* XXX: The physical address space is limited to 42 bits
On 16/06/2016 19:12, Dr. David Alan Gilbert (git) wrote:
> if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
> -/* 64 bit processor */
> -/* XXX: The physical address space is limited to 42 bits in exec.c. */
> -*eax = 0x3028; /* 48 bits virtual, 40 bit
From: "Dr. David Alan Gilbert"
Currently QEMU sets the x86 number of physical address bits to the
magic number 40. This is only correct on some small AMD systems;
Intel systems tend to have 36, 39, 46 bits, and large AMD systems
tend to have 48.
Having the value different from your actual hardw
24 matches
Mail list logo
