On 10/27/2016 11:04 AM, Roger Pau Monne wrote:
> On Thu, Oct 27, 2016 at 10:40:52AM -0400, Boris Ostrovsky wrote:
>>
>> On 10/27/2016 10:30 AM, Jan Beulich wrote:
>> On 27.10.16 at 16:15, wrote:
On 10/27/2016 10:02 AM, Jan Beulich wrote:
On 27.10.16 at 15:51, wrote:
>> I re-
On Thu, Oct 27, 2016 at 09:20:00AM -0600, Jan Beulich wrote:
> >>> On 27.10.16 at 17:04, wrote:
> > I prefer this solution because it seems simpler and less likely to cause
> > future issues, but if this seems like too much fuss I can always try to
> > place the RSDP on top of the original one a
>>> On 27.10.16 at 17:04, wrote:
> I prefer this solution because it seems simpler and less likely to cause
> future issues, but if this seems like too much fuss I can always try to
> place the RSDP on top of the original one and shadow that page. From the
> information I've been able to find o
On Thu, Oct 27, 2016 at 10:40:52AM -0400, Boris Ostrovsky wrote:
>
>
> On 10/27/2016 10:30 AM, Jan Beulich wrote:
> > > > > On 27.10.16 at 16:15, wrote:
> > > On 10/27/2016 10:02 AM, Jan Beulich wrote:
> > > > > > > On 27.10.16 at 15:51, wrote:
> > > > > I re-read this thread and I am not sure
On 10/27/2016 10:30 AM, Jan Beulich wrote:
On 27.10.16 at 16:15, wrote:
On 10/27/2016 10:02 AM, Jan Beulich wrote:
On 27.10.16 at 15:51, wrote:
I re-read this thread and I am not sure I understand why we can't keep
host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
we c
>>> On 27.10.16 at 16:15, wrote:
> On 10/27/2016 10:02 AM, Jan Beulich wrote:
> On 27.10.16 at 15:51, wrote:
>>> I re-read this thread and I am not sure I understand why we can't keep
>>> host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
>>> we can place our versions of R
On 10/27/2016 10:02 AM, Jan Beulich wrote:
On 27.10.16 at 15:51, wrote:
I re-read this thread and I am not sure I understand why we can't keep
host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
we can place our versions of RSDT/XSDT at the address that the
descriptor point
>>> On 27.10.16 at 15:51, wrote:
> I re-read this thread and I am not sure I understand why we can't keep
> host's RSDP descriptor. We are not mapping dom0 memory 1:1 (right?) so
> we can place our versions of RSDT/XSDT at the address that the
> descriptor points to.
>
> Unless that address is
On 10/27/2016 07:13 AM, Roger Pau Monne wrote:
On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
I've initially used a back-listing approach. We can always change this later
on.
So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
crafting a new custom RSDT
>>> On 27.10.16 at 13:13, wrote:
> On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
>> I've initially used a back-listing approach. We can always change this
>> later
>> on.
>>
>> So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
>>
On Wed, Oct 26, 2016 at 01:14:16PM -0400, Boris Ostrovsky wrote:
>
> I've initially used a back-listing approach. We can always change this
> later
> on.
>
> So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
> crafting a new custom RSDT (and in
On Thu, Oct 27, 2016 at 01:25:40AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 18:03, wrote:
> > On Wed, Oct 26, 2016 at 09:16:55AM -0600, Jan Beulich wrote:
> >> >>> On 26.10.16 at 17:08, wrote:
> >> > On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >> >> >>> On 26.10.16 at 13:
>>> On 26.10.16 at 19:14, wrote:
> I've initially used a back-listing approach. We can always change this
> later
> on.
>
> So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
> crafting a new custom RSDT (and in fact I'm setting rsdt_physical_address
>>> On 26.10.16 at 18:03, wrote:
> On Wed, Oct 26, 2016 at 09:16:55AM -0600, Jan Beulich wrote:
>> >>> On 26.10.16 at 17:08, wrote:
>> > On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
>> >> >>> On 26.10.16 at 13:35, wrote:
>> >> > On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beuli
I've initially used a back-listing approach. We can always change this
later
on.
So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not
crafting a new custom RSDT (and in fact I'm setting rsdt_physical_address
=
0 in the RSDP together wi
On Wed, Oct 26, 2016 at 09:16:55AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 17:08, wrote:
> > On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >> >>> On 26.10.16 at 13:35, wrote:
> >> > On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
> >> >> Taking an abstract per
>>> On 26.10.16 at 17:08, wrote:
> On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
>> >>> On 26.10.16 at 13:35, wrote:
>> > On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
>> >> Taking an abstract perspective I agree with Andrew that we should
>> >> be whitelisting here.
On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 13:35, wrote:
> > On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
> >> Taking an abstract perspective I agree with Andrew that we should
> >> be whitelisting here. However, as you already see from the li
>>> On 26.10.16 at 13:35, wrote:
> On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
>> Taking an abstract perspective I agree with Andrew that we should
>> be whitelisting here. However, as you already see from the list you
>> provided (which afaict is far from complete wrt ACPI 6.1),
On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 17:35, wrote:
> > On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
> >> >>> On 27.09.16 at 17:57, wrote:
> >> > +static void __init acpi_zap_table_signature(char *name)
> >> > +{
> >> > +struct acpi_
>>> On 12.10.16 at 17:35, wrote:
> On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > +static void __init acpi_zap_table_signature(char *name)
>> > +{
>> > +struct acpi_table_header *table;
>> > +acpi_status status;
>> > +union {
>> >
On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > FWIW, I think that the current approach that I've used in order to craft the
> > MADT is not the best one, IMHO it would be better to place the MADT at the
> > end of the E820_ACPI region (expanding
On 06/10/16 16:40, Jan Beulich wrote:
On 27.09.16 at 17:57, wrote:
>> FWIW, I think that the current approach that I've used in order to craft the
>> MADT is not the best one, IMHO it would be better to place the MADT at the
>> end of the E820_ACPI region (expanding it's size one page), and m
>>> On 27.09.16 at 17:57, wrote:
> FWIW, I think that the current approach that I've used in order to craft the
> MADT is not the best one, IMHO it would be better to place the MADT at the
> end of the E820_ACPI region (expanding it's size one page), and modify the
> XSDT/RSDT in order to point to
This maps all the regions in the e820 marked as E820_ACPI or E820_NVS and
the top-level ACPI tables discovered by Xen to Dom0 1:1. It also shadows the
page(s) where the native MADT is placed by mapping a RAM page over it,
copying the original data and modifying it afterwards in order to represent
t
25 matches
Mail list logo
