On Tue, Jan 20, 2015 at 01:41:16PM +0100, Igor Mammedov wrote:
> On Tue, 20 Jan 2015 12:35:47 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Tue, Jan 20, 2015 at 10:59:43AM +0100, Igor Mammedov wrote:
> > > On Mon, 19 Jan 2015 21:29:57 +0200
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Mon,
On Tue, 20 Jan 2015 12:35:47 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Jan 20, 2015 at 10:59:43AM +0100, Igor Mammedov wrote:
> > On Mon, 19 Jan 2015 21:29:57 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote:
> > > >
> > > >
> > >
On Tue, Jan 20, 2015 at 10:59:43AM +0100, Igor Mammedov wrote:
> On Mon, 19 Jan 2015 21:29:57 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote:
> > >
> > >
> > > On 19/01/2015 18:14, Igor Mammedov wrote:
> > > > I'm fine with moving "SMC ou
On 20/01/2015 10:59, Igor Mammedov wrote:
>>> > > Yes, trimming is better than putting it in the DSDT, at least for simple
>>> > > devices such as SMC and pvpanic.
> So are we dropping 1-2/4 from this series?
> I need to know on top of what to rebase. I'll take care of moving SMC to SSDT.
Do not
On Mon, 19 Jan 2015 21:29:57 +0200
"Michael S. Tsirkin" wrote:
> On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote:
> >
> >
> > On 19/01/2015 18:14, Igor Mammedov wrote:
> > > I'm fine with moving "SMC out of the per-machine-type AML", should be
> > > a separate patch anyway. But pa
On Mon, Jan 19, 2015 at 08:57:55PM +0100, Paolo Bonzini wrote:
>
>
> On 19/01/2015 20:33, Michael S. Tsirkin wrote:
> >>> > > so we probably should apply anyway the patch of
> >>> > > mine that allows the DSDT size to change; and we probably should pay
> >>> > > attention to SSDT, and version it.
On 19/01/2015 20:33, Michael S. Tsirkin wrote:
>>> > > so we probably should apply anyway the patch of
>>> > > mine that allows the DSDT size to change; and we probably should pay
>>> > > attention to SSDT, and version it.
> Oh, missed that.
> You mean this: "Add padding after the DSDT"?
Yes.
>
On Mon, Jan 19, 2015 at 09:29:57PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote:
> >
> >
> > On 19/01/2015 18:14, Igor Mammedov wrote:
> > > I'm fine with moving "SMC out of the per-machine-type AML", should be
> > > a separate patch anyway. But
On Mon, Jan 19, 2015 at 06:26:55PM +0100, Paolo Bonzini wrote:
>
>
> On 19/01/2015 18:14, Igor Mammedov wrote:
> > I'm fine with moving "SMC out of the per-machine-type AML", should be
> > a separate patch anyway. But patch-able SMC being in DSDT is our mistake
> > that we allowed it to slip ther
On 19/01/2015 18:14, Igor Mammedov wrote:
> I'm fine with moving "SMC out of the per-machine-type AML", should be
> a separate patch anyway. But patch-able SMC being in DSDT is our mistake
> that we allowed it to slip there and should be better moved to SSDT rather
> than staying in DSDT and maki
On Mon, 19 Jan 2015 16:41:26 +0100
Paolo Bonzini wrote:
>
>
> On 19/01/2015 16:15, Igor Mammedov wrote:
> > On Wed, 24 Dec 2014 17:07:35 +0100
> > Paolo Bonzini wrote:
> >
> >> This part of the ACPI tables can vary in size across machine types, but
> > s/machine types/QEMU versions/ since it
On 19/01/2015 16:15, Igor Mammedov wrote:
> On Wed, 24 Dec 2014 17:07:35 +0100
> Paolo Bonzini wrote:
>
>> This part of the ACPI tables can vary in size across machine types, but
> s/machine types/QEMU versions/ since it doesn't change its size on machine
> type.
Right.
>> does not depend on
On Wed, Dec 24, 2014 at 05:07:35PM +0100, Paolo Bonzini wrote:
> This part of the ACPI tables can vary in size across machine types, but
> does not depend on the command-line. It is an SSDT just because it is
> the same for i440fx and Q35, and making it an SSDT made the code a bit
> simpler. Howe
On Wed, 24 Dec 2014 17:07:35 +0100
Paolo Bonzini wrote:
> This part of the ACPI tables can vary in size across machine types, but
s/machine types/QEMU versions/ since it doesn't change its size on machine
type.
> does not depend on the command-line. It is an SSDT just because it is
s/does not/i
This part of the ACPI tables can vary in size across machine types, but
does not depend on the command-line. It is an SSDT just because it is
the same for i440fx and Q35, and making it an SSDT made the code a bit
simpler. However, it also complicates backwards compatibility, so
merge it with the
15 matches
Mail list logo
