On 02/10/2016 09:51 AM, Roger Pau Monné wrote:
The detection of local APIC and IO APICs is quite isolated from each
other, and the failure to find any IO APICs should not prevent local
APICs from being enabled. Although I don't think there's any hardware
with this setup, such configuration would
El 10/2/16 a les 13:53, Jan Beulich ha escrit:
On 10.02.16 at 13:01, wrote:
>> El 9/2/16 a les 14:24, Jan Beulich ha escrit:
>> On 08.02.16 at 20:03, wrote:
* 2. HVMlite with (or capable to) PCI-passthrough
---
The current
>>> On 10.02.16 at 13:01, wrote:
> El 9/2/16 a les 14:24, Jan Beulich ha escrit:
> On 08.02.16 at 20:03, wrote:
>>> The layout of each entry in the module structure is the following:
>>>
>>> 0 ++
>>>| paddr | Physical address of the module.
>>> 4 +--
El 9/2/16 a les 14:24, Jan Beulich ha escrit:
On 08.02.16 at 20:03, wrote:
>> * `eflags`: all user settable bits are clear.
>
> The word "user" here can be mistaken. Perhaps better "all modifiable
> bits"?
>
>> All other processor registers and flag bits are unspecified. The OS is in
>> cha
>>> On 09.02.16 at 17:32, wrote:
> El 9/2/16 a les 14:41, Jan Beulich ha escrit:
> On 09.02.16 at 14:00, wrote:
>>> Hm, I guess I'm overlooking something, but I think Xen checks the ACPI
>>> tables, see xen/arch/x86/x86_64/mmconfig-shared.c:400:
>>>
>>> if (pci_mmcfg_check_hostbridge()) {
>>> On 09.02.16 at 17:26, wrote:
> On Tue, 9 Feb 2016, Jan Beulich wrote:
>> >>> On 09.02.16 at 16:06, wrote:
>> > On Tue, 9 Feb 2016, Jan Beulich wrote:
>> >> Will STAO be sufficient for everything that may need customization?
>> >> I'm particularly worried about processor related methods in DSD
El 9/2/16 a les 14:41, Jan Beulich ha escrit:
On 09.02.16 at 14:00, wrote:
>> Hm, I guess I'm overlooking something, but I think Xen checks the ACPI
>> tables, see xen/arch/x86/x86_64/mmconfig-shared.c:400:
>>
>> if (pci_mmcfg_check_hostbridge()) {
>> unsigned int i;
>>
>>
>>> On 09.02.16 at 17:17, wrote:
> On 09/02/16 16:15, Jan Beulich wrote:
> On 09.02.16 at 16:06, wrote:
>>> On Tue, 9 Feb 2016, Jan Beulich wrote:
Will STAO be sufficient for everything that may need customization?
I'm particularly worried about processor related methods in DSDT or
On Tue, 9 Feb 2016, Jan Beulich wrote:
> >>> On 09.02.16 at 16:06, wrote:
> > On Tue, 9 Feb 2016, Jan Beulich wrote:
> >> Will STAO be sufficient for everything that may need customization?
> >> I'm particularly worried about processor related methods in DSDT or
> >> SSDT, which - if we're really
On 09/02/16 16:15, Jan Beulich wrote:
On 09.02.16 at 16:06, wrote:
>> On Tue, 9 Feb 2016, Jan Beulich wrote:
>>> Will STAO be sufficient for everything that may need customization?
>>> I'm particularly worried about processor related methods in DSDT or
>>> SSDT, which - if we're really meanin
>>> On 09.02.16 at 16:06, wrote:
> On Tue, 9 Feb 2016, Jan Beulich wrote:
>> Will STAO be sufficient for everything that may need customization?
>> I'm particularly worried about processor related methods in DSDT or
>> SSDT, which - if we're really meaning to do as you say - would need
>> to be li
On 02/08/2016 02:03 PM, Roger Pau Monné wrote:
The format of the boot start info structure is the following (pointed to
be %ebx):
NOTE: nothing will be loaded at physical address 0, so a 0 value in any of the
address fields should be treated as not present.
0 ++
| magic
On Tue, 9 Feb 2016, Jan Beulich wrote:
> > In the case of the hardware domain, Xen has traditionally passed-through the
> > native ACPI tables to the guest. This is something that of course we still
> > want to do, but in the case of HVMlite Xen will have to make sure that
> > the data passed in th
>>> On 09.02.16 at 15:36, wrote:
> On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from ACPI, in the
absence of any physical hard
On 09/02/16 14:36, Boris Ostrovsky wrote:
> On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from
ACPI, in the
absence of any
On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from ACPI, in the
absence of any physical hardware device no ACPI tables will be provided. The
pres
>>> On 09.02.16 at 14:00, wrote:
> El 9/2/16 a les 13:10, Jan Beulich ha escrit:
> On 09.02.16 at 12:58, wrote:
>>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
On 08/02/16 19:03, Roger Pau Monné wrote:
> * PCI Express MMCFG: if Xen is able to identify any of these regions at
>
>>> On 08.02.16 at 20:03, wrote:
> Boot ABI
>
>
> Since the Xen entry point into the kernel can be different from the
> native entry point, a `ELFNOTE` is used in order to tell the domain
> builder how to load and jump into the kernel entry point:
>
> ELFNOTE(Xen, XEN_ELFNOTE_PHYS32
El 9/2/16 a les 13:10, Jan Beulich ha escrit:
On 09.02.16 at 12:58, wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
* PCI Express MMCFG: if Xen is able to identify any of these regions at
boot
time they will also be m
>>> On 09.02.16 at 12:58, wrote:
> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>> On 08/02/16 19:03, Roger Pau Monné wrote:
>>> * PCI Express MMCFG: if Xen is able to identify any of these regions at
>>> boot
>>>time they will also be made available to the guest at the same position
>>>
El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
> On 08/02/16 19:03, Roger Pau Monné wrote:
>> The format of the boot start info structure is the following (pointed to
>> be %ebx):
>>
>> NOTE: nothing will be loaded at physical address 0, so a 0 value in any of
>> the
>> address fields should be t
On 08/02/16 19:03, Roger Pau Monné wrote:
> The format of the boot start info structure is the following (pointed to
> be %ebx):
>
> NOTE: nothing will be loaded at physical address 0, so a 0 value in any of the
> address fields should be treated as not present.
>
> 0 ++
>| mag
On 02/08/2016 02:03 PM, Roger Pau Monné wrote:
* PCI BARs: it's not possible for Xen to know the position of the BARs of
the PCI devices without hardware domain interaction. In order to have
the BARs of PCI devices properly mapped the hardware domain needs to
call the PHYSDEVOP_p
23 matches
Mail list logo
