On 08/02/16 12:10, Stefano Stabellini wrote:
> On Fri, 5 Feb 2016, Andrew Cooper wrote:
>> The current pci-front/back and Qemu-based methods have substantial
>> architectural deficiencies, and are incredibly fragile to change. When
>> was the last XSA to PCI Passthrough which didn't end up requiri
On Fri, 5 Feb 2016, Andrew Cooper wrote:
> The current pci-front/back and Qemu-based methods have substantial
> architectural deficiencies, and are incredibly fragile to change. When
> was the last XSA to PCI Passthrough which didn't end up requiring
> further bugfixes to undo the collateral damag
On 05/02/16 18:05, Tim Deegan wrote:
> At 17:14 + on 05 Feb (1454692488), Andrew Cooper wrote:
>> On 05/02/16 16:01, Tim Deegan wrote:
>>> At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
Hello,
I've Cced a bunch of people who have expressed interest in the HVMlite
>
At 17:14 + on 05 Feb (1454692488), Andrew Cooper wrote:
> On 05/02/16 16:01, Tim Deegan wrote:
> > At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
> >> Hello,
> >>
> >> I've Cced a bunch of people who have expressed interest in the HVMlite
> >> design/implementation, both from a X
On 05/02/16 16:01, Tim Deegan wrote:
> At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
>> Hello,
>>
>> I've Cced a bunch of people who have expressed interest in the HVMlite
>> design/implementation, both from a Xen or OS point of view. If you
>> would like to be removed, please say s
At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
> Hello,
>
> I've Cced a bunch of people who have expressed interest in the HVMlite
> design/implementation, both from a Xen or OS point of view. If you
> would like to be removed, please say so and I will remove you in
> further iterat
El 5/2/16 a les 17:01, Tim Deegan ha escrit:
> At 18:48 +0100 on 04 Feb (1454611694), Roger Pau Monné wrote:
>> Hello,
>>
>> I've Cced a bunch of people who have expressed interest in the HVMlite
>> design/implementation, both from a Xen or OS point of view. If you
>> would like to be removed, plea
El 5/2/16 a les 16:29, Jan Beulich ha escrit:
On 05.02.16 at 16:00, wrote:
>> El 5/2/16 a les 15:31, Jan Beulich ha escrit:
>> On 05.02.16 at 15:27, wrote:
El 5/2/16 a les 14:22, Jan Beulich ha escrit:
> Also consider e.g. the device IRQ which the
> serial driver may be usin
>>> On 05.02.16 at 16:00, wrote:
> El 5/2/16 a les 15:31, Jan Beulich ha escrit:
> On 05.02.16 at 15:27, wrote:
>>> El 5/2/16 a les 14:22, Jan Beulich ha escrit:
Also consider e.g. the device IRQ which the
serial driver may be using: We specifically suppress modifications to
RT
El 5/2/16 a les 15:31, Jan Beulich ha escrit:
On 05.02.16 at 15:27, wrote:
>> El 5/2/16 a les 14:22, Jan Beulich ha escrit:
>> On 05.02.16 at 12:50, wrote:
El 5/2/16 a les 12:45, Jan Beulich ha escrit:
On 05.02.16 at 12:30, wrote:
>> El 5/2/16 a les 11:40, Jan Beulich
El 5/2/16 a les 15:44, Ian Campbell ha escrit:
> On Thu, 2016-02-04 at 20:33 +0100, Roger Pau Monné wrote:
>> El 4/2/16 a les 19:22, Andrew Cooper ha escrit:
>>> On 04/02/16 17:48, Roger Pau Monné wrote:
Hello,
I've Cced a bunch of people who have expressed interest in the
HVMli
On Thu, 2016-02-04 at 20:33 +0100, Roger Pau Monné wrote:
> El 4/2/16 a les 19:22, Andrew Cooper ha escrit:
> > On 04/02/16 17:48, Roger Pau Monné wrote:
> > > Hello,
> > >
> > > I've Cced a bunch of people who have expressed interest in the
> > > HVMlite
> > > design/implementation, both from a
>>> On 05.02.16 at 15:27, wrote:
> El 5/2/16 a les 14:22, Jan Beulich ha escrit:
> On 05.02.16 at 12:50, wrote:
>>> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
>>> On 05.02.16 at 12:30, wrote:
> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
> On 05.02.16 at 10:50, wrote:
>
El 5/2/16 a les 14:22, Jan Beulich ha escrit:
On 05.02.16 at 12:50, wrote:
>> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
>> On 05.02.16 at 12:30, wrote:
El 5/2/16 a les 11:40, Jan Beulich ha escrit:
On 05.02.16 at 10:50, wrote:
>> For legacy PCI interrupts, we can p
>>> On 05.02.16 at 12:50, wrote:
> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
> On 05.02.16 at 12:30, wrote:
>>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>>> On 05.02.16 at 10:50, wrote:
> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
> to proper
El 5/2/16 a les 12:45, Jan Beulich ha escrit:
On 05.02.16 at 12:30, wrote:
>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>> On 05.02.16 at 10:50, wrote:
For legacy PCI interrupts, we can parse the MADT inside of Xen in order
to properly setup the lines/overwrites and inject
>>> On 05.02.16 at 12:30, wrote:
> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
> On 05.02.16 at 10:50, wrote:
>>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>>> to properly setup the lines/overwrites and inject the interrupts that
>>> are not handled by Xen stra
El 5/2/16 a les 11:40, Jan Beulich ha escrit:
On 05.02.16 at 10:50, wrote:
>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>> to properly setup the lines/overwrites and inject the interrupts that
>> are not handled by Xen straight into the hardware domain. This will
>>> On 05.02.16 at 12:04, wrote:
> On 05/02/16 10:40, Jan Beulich wrote:
> On 05.02.16 at 10:50, wrote:
>>> Status flag? Why don't we just say that all user-settable bits in the
>>> status register will be set to 0 (or cleared)?
>> Would be an option too.
>
> What about the ID bit, which pro
On 05/02/16 10:40, Jan Beulich wrote:
On 05.02.16 at 10:50, wrote:
>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>> to properly setup the lines/overwrites and inject the interrupts that
>> are not handled by Xen straight into the hardware domain. This will
>> requ
>>> On 05.02.16 at 10:50, wrote:
> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
> to properly setup the lines/overwrites and inject the interrupts that
> are not handled by Xen straight into the hardware domain. This will
> require us to be able to emulate the same topol
On Thu, 2016-02-04 at 18:48 +0100, Roger Pau Monné wrote:
> Hello,
>
> I've Cced a bunch of people who have expressed interest in the HVMlite
> design/implementation,
I think "HVMlite" has now reached the point where we should start the
transition from PVH (classic) to PVH (hvmlite) naming rathe
El 5/2/16 a les 10:12, Jan Beulich ha escrit:
On 04.02.16 at 19:22, wrote:
>> On 04/02/16 17:48, Roger Pau Monné wrote:
>>> - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ
>>>event channels?
>>> - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
>>
>>
>>> On 04.02.16 at 19:22, wrote:
> On 04/02/16 17:48, Roger Pau Monné wrote:
>> - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ
>>event channels?
>> - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
>
> +1000, for both.
I'm a little lost here: However ni
El 4/2/16 a les 21:17, Boris Ostrovsky ha escrit:
> On 02/04/2016 02:21 PM, Roger Pau Monné wrote:
>> El 4/2/16 a les 19:51, Samuel Thibault ha escrit:
>>> Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
> The format of the boot sta
Andrew Cooper, on Thu 04 Feb 2016 22:25:47 +, wrote:
> On 04/02/2016 22:21, Samuel Thibault wrote:
> > Boris Ostrovsky, on Thu 04 Feb 2016 14:18:46 -0500, wrote:
> >> On 02/04/2016 02:09 PM, Samuel Thibault wrote:
> >>> Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
> struc
On 04/02/2016 22:21, Samuel Thibault wrote:
> Boris Ostrovsky, on Thu 04 Feb 2016 14:18:46 -0500, wrote:
>> On 02/04/2016 02:09 PM, Samuel Thibault wrote:
>>> Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
struct hvm_start_info {
#define HVM_START_MAGIC_VALUE 0x336ec57
Roger Pau Monné, on Thu 04 Feb 2016 20:21:24 +0100, wrote:
> > +1
> > We need that to pass parameters to gnumach modules.
>
> Hm, parameters as in a string that's paired with a module,
That, yes. Just like the kernel command line. One per module.
> I see that multiboot provides a string associat
Boris Ostrovsky, on Thu 04 Feb 2016 14:18:46 -0500, wrote:
> On 02/04/2016 02:09 PM, Samuel Thibault wrote:
> >Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
> >> struct hvm_start_info {
> >> #define HVM_START_MAGIC_VALUE 0x336ec578
> >> uint32_t magic; /* Co
On 04/02/16 20:29, Konrad Rzeszutek Wilk wrote:
> If there is more than one module, how is the guest expected to sort out
> which module is what?
>>> In general I was expecting this would be done by position, or if that's
>>> not enough an additional module (at either position 0 or n) shoul
> >>>If there is more than one module, how is the guest expected to sort out
> >>>which module is what?
> >In general I was expecting this would be done by position, or if that's
> >not enough an additional module (at either position 0 or n) should be
> >passed to contain that information.
>
> The
On 02/04/2016 02:33 PM, Roger Pau Monné wrote:
So we should provide a lapic/ioapic set of options to xl configuration
files?
We already have 'apic' option. We can also use 'acpi=false' since then
that will mean no MADT and thus no APIC/IOAPIC.
-boris
__
On 02/04/2016 02:21 PM, Roger Pau Monné wrote:
El 4/2/16 a les 19:51, Samuel Thibault ha escrit:
Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
The format of the boot start info structure is the following (pointed to
be %ebx):
st
El 4/2/16 a les 19:22, Andrew Cooper ha escrit:
> On 04/02/16 17:48, Roger Pau Monné wrote:
>> Hello,
>>
>> I've Cced a bunch of people who have expressed interest in the HVMlite
>> design/implementation, both from a Xen or OS point of view. If you
>> would like to be removed, please say so and I
El 4/2/16 a les 19:51, Samuel Thibault ha escrit:
> Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
>> On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
>>> The format of the boot start info structure is the following (pointed to
>>> be %ebx):
>>>
>>> struct hvm_start_info {
>>> #de
On 02/04/2016 02:09 PM, Samuel Thibault wrote:
Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
struct hvm_start_info {
#define HVM_START_MAGIC_VALUE 0x336ec578
uint32_t magic; /* Contains the magic value 0x336ec578
*/
Roger Pau Monné, on Thu 04 Feb 2016 18:48:14 +0100, wrote:
> struct hvm_start_info {
> #define HVM_START_MAGIC_VALUE 0x336ec578
> uint32_t magic; /* Contains the magic value 0x336ec578
>*/
> /* ("xEn3" with the 0x80 bit of the
Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
> On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
> >The format of the boot start info structure is the following (pointed to
> >be %ebx):
> >
> > struct hvm_start_info {
> > #define HVM_START_MAGIC_VALUE 0x336ec578
> > uint3
On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
The format of the boot start info structure is the following (pointed to
be %ebx):
struct hvm_start_info {
#define HVM_START_MAGIC_VALUE 0x336ec578
uint32_t magic; /* Contains the magic value 0x336ec578
*/
On 04/02/16 17:48, Roger Pau Monné wrote:
> Hello,
>
> I've Cced a bunch of people who have expressed interest in the HVMlite
> design/implementation, both from a Xen or OS point of view. If you
> would like to be removed, please say so and I will remove you in
> further iterations. The same app
Hello,
I've Cced a bunch of people who have expressed interest in the HVMlite
design/implementation, both from a Xen or OS point of view. If you
would like to be removed, please say so and I will remove you in
further iterations. The same applies if you want to be added to the Cc.
This is an i
41 matches
Mail list logo
