e committers can check in anything that has his Ack to the
> Vixen branch, and the Security Team can post new signed tags when
> appropriate.
>
> It looked like Anthony had some issues with the most recent patch though.
I am very happy to review stuff for the Vixen branch but I'
RHND_COOKED) )
> +__serial_putc(port, '\r' | ((handle & SERHND_HI) ? 0x80 : 0x00));
> +
> +if ( handle & SERHND_HI )
> +c |= 0x80;
> + else if ( handle & SERHND_LO )
> +c &= 0x7f;
> +
> +__serial_putc(por
>
> Is this expected? It doesn't seem workable if so.
Usually this means there is a dangling backend that wasn't properly
terminated. It would be useful to xenstore-ls the domain and see
which backend is not in a disconnected state.
Regards,
Anthony Liguori
> Cheers,
> An
ad a plan and have been working together in a common direction but
the embargo broke early and we ran out of time.
We are now trying to figure out what to do given that. We're all
trying to make the best of a bad situation.
Regards,
Anthony Liguori
__
what's in this branch https://github.com/aliguori/xen/tree/vi
> xen-upstream-v2 both as the host hypervisor and as the shim.
Please test with v1.
Regards,
Anthony Liguori
>
ready to release
>> - When ready, advisory and HOWTO should include who should use this
>> option and how
>> - Either check the series into a branch on xenbits, or into
>> staging-4.10
>> - HOWTO-pvh to be included in the advisory.
>>
>> This should al
n if the solution has reduced functionality, is better than
>> > delaying for the perfect solution. I suggest we go with Amazon's series
>> > first and produce something this week, then we seek to merge the two
>> > solutions. Anthony has agreed to be on the hook to
in spurious debug printks if you have guest
loglvl set to debug but no real harm otherwise.
Regards,
Anthony Liguori
> * I see this message when I create the domain:
> xc: error: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest'
> section found: Invalid k
tage of merging to staging is that it becomes possible to
bisect regressions.
There isn't really much of a user facing difference here so if the entirety
of Vixen was replaced under the covers for 4.11, as long as we are able
to test continuously and avoid regres
re yet. There's something in liuw's pvshim branch
that you might want to look at.
Regards,
Anthony Liguori
> --Sarah
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/
event channels that are
forwarded to the hypervisor we're running under.
This makes the code more readable in many places.
Signed-off-by: Jan H. Schönherr
Signed-off-by: Anthony Liguori
---
xen/common/event_channel.c | 87 --
xen/include/xen/ev
From: Anthony Liguori
In order to be able to assign the Xenstore page into the Vixen guest,
we need struct page_info's to exist. We do this by modifying the
e820 table early in boot and then using the badpages handling to
prevent these pages from being added to the xenheap.
Since these
From: Anthony Liguori
The grant table is a region of guest memory that contains GMFNs
which in PV are MFNs but are PFNs in HVM. Since a Vixen guest MFN
is an HVM PFN, we can pass this table directly through to the outer
Xen which cuts down considerably on overhead.
We do not forward most of
From: Jan H. Schönherr
While the hwdom_shutdown() is able to reboot the system, it fails to
properly power it off. With SCHEDOP_shutdown, we delegate the problem.
Signed-off-by: Jan H. Schönherr
---
xen/common/domain.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/com
From: Anthony Liguori
For Vixen, we do not want to pass through all event channel
operations as HVM guests do not have nearly as many event channel
interactions as PV and on older versions of Xen, there is no reliable
way to wake up an event channel on VCPU != 0 leading to a variety of
deadlocks
From: Anthony Liguori
Vixen (Virtualized Xen) is a paravirtual mode of Xen where
paravirtual I/O is passed through from the parent hypervisor
all the way through the dom0 guest. The dom0 guest is also
deprivileged and renumbered to give the appearance that it
is running as a normal PV guest
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
xen/arch/x86/guest/Makefile | 1 +
xen/arch/x86/guest/hypercall_page.S | 79 ++
xen/arch/x86/guest/xen.c | 5 ++
xen/arch/x86/xen.lds.S| 1 +
xen/include/asm-x86/guest.h
From: Jan H. Schönherr
The function originally did the following unconditionally:
send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
The new variant should reflect the non-Vixen case correctly.
Signed-off-by: Jan H. Schönherr
Signed-off-by: Anthony Liguori
From: Anthony Liguori
Our initial approach exposed the console ring directly to guests
which worked well except for the fact that very old versions of Xen
did not support console ring for HVM guests. It also proved to
be complicated from a management tool perspective since both the
serial
From: Roger Pau Monne
Signed-off-by: Roger Pau Monné
Signed-off-by: Anthony Liguori
---
v2 -> v3
- adapted for Vixen
---
xen/arch/x86/guest/vixen.c| 110 ++
xen/common/memory.c | 14 +
xen/include/asm-x86/guest/vixen.h |
From: Anthony Liguori
This patch registers an interrupt handler using either an INTx
interrupt from the platform PCI device, CALLBACK_IRQ vector
delivery, or evtchn_upcall_vector depending on what the parent
hypervisor supports.
The event channel polling code comes from Linux but uses the
From: Anthony Liguori
The dom0 builder requires a number of modifications in order to be
able to launch unprivileged guests. The console and store pages
must be mapped in a specific location within the guest's initial
page table.
We also have to setup the start info to be what's ex
From: Anthony Liguori
Otherwise when time sharing a physical CPU, the calculation can
be bogus resulting in time drift for the guest due to improper
frequency within pvclock.
Signed-off-by: Anthony Liguori
---
xen/arch/x86/guest/vixen.c| 22 ++
xen/arch/x86/time.c
From: Anthony Liguori
This allows for proper accounting of steal time within the guest.
Signed-off-by: Anthony Liguori
---
xen/common/domain.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ede377c..780f8ff 100644
--- a/xen/common
From: Anthony Liguori
We split initialization of Vixen into two parts. The first part
just detects the presence of an HVM hypervisor so that we can
figure out whether to modify the e820 table.
The later initialization is used to actually map the shared_info
structure from the parent hypervisor
From: Anthony Liguori
This is necessary to trigger event channel upcalls but it is also
useful to passthrough the full version information such that the
guest believes it is running on the parent Xen.
Signed-off-by: Matt Wilson
Signed-off-by: Anthony Liguori
---
v1 -> v2
- don't pass
Signed-off-by: Anthony Liguori
---
v1 -> v2
- adapted for Vixen
---
xen/arch/x86/pv/dom0_build.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index a554629..2bc6339 100644
--- a/xen/arch/x86/pv/dom0_build.c
+
From: Matt Wilson
When using Vixen, it is helpful to get the Xen messages in a
separate channel than the console output. Add an option to
output to the QEMU backdoor logging port.
Signed-off-by: Matt Wilson
---
v1 -> v2
- #ifdef for !x86_64
---
xen/drivers/char/console.c | 35 +++
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
v1 -> v2
- ARM stubs
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/guest/Makefile | 1 +
xen/arch/x86/guest/xen.c| 75 +
xen/arch/x86/setup.c| 4 +++
xen/include/as
From: Anthony Liguori
Only print the banner if the log threshold is at least info.
For Vixen guests, we want the console output to be exactly what the
PV guest would show on it's own. That means the inner Xen banner
can potentially break automation that assumes a specific type of
co
From: Anthony Liguori
Some older guests special case domid=0 instead of checking the
shared info flags so in order to get PV drivers loaded properly,
we need to make the guest always appear with a domid != 0.
While the Vixen domain is the hardware domain, we don't want it
to behave that w
From: Anthony Liguori
Our intention is for the Vixen guest to be deprivileged so we need
to avoid permitting access to each IRQ even though it is technically
the hardware domain.
Signed-off-by: Anthony Liguori
---
xen/arch/x86/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Anthony Liguori
CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
appears to be very difficult to isolate the hypervisor's page tables
from PV domUs while maintaining ABI compatibility. Instead of trying
to make a KPTI-like approach work for Xen PV, it seems reaso
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
xen/arch/x86/Kconfig | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7c45829..07530bf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -117,6 +117,23 @@ c
From: Jan H. Schönherr
Intel says for CPUID leaf 0Bh:
"Software must not use EBX[15:0] to enumerate processor
topology of the system. This value in this field
(EBX[15:0]) is only intended for display/diagnostic
purposes. The actual number of logical processors
available to BIOS/OS/
ok to review future
> patches. ;-)
Thanks Wei.
I merged in ballooning support and that seems to be working okay.
Unfortunately, vcpu hotplug crashes during SMP boot up because we're
passing through runstate registration to make steal time accounting work
but there seems to b
On Mon, Jan 8, 2018 at 8:05 AM, Jan Beulich wrote:
>>>> On 04.01.18 at 14:06, wrote:
>> From: Roger Pau Monne
>>
>> Note that the unmask and the virq operations are handled by the shim
>> itself, and that FIFO event channels are not exposed to the guest.
>
>> I'm happy to redirect effort to PVH shim if that's what the solution
>> is going to be.
>>
>> I obviously prefer the HVM approach as it works on a broad range of Xen
>> versions
>> without modification but I'm keen to ge
still
> help all that don't require it. It is only a partial fix by nature
> anyway.
Can people be a bit more explicit about what they think should be done here?
I'm happy to redirect effort to PVH shim if that's what the solution
is going to be.
I obviously prefer the HVM a
;s
not that big so it should take all that
long to do so.
I think v3 of my series is likely the closest to something that can be
merged this week.
Regards,
Anthony Liguori
> Ian.
>
> ___
> Xen-devel mailing list
> Xen-dev
oesn't work? I haven't tested but I cannot
imagine why it wouldn't.
Ballooning is trivial. I can send a V3 this morning with ballooning.
Regards,
Anthony Liguori
I was hoping someone would have an opinion about how hard it would be
to take Amazon
SUPPORT.md
> will also need an update.
It's not particularly hard to plumb through I think but if you are
using PCI passthrough for PV, then you really shouldn't worry about
Spectre/Meltdown. That PV guest can already read all of physical
memory (since no IOMMU is used) and they can also write to all
physical memory which is far worse than what you can do with
Spectre/Meltdown.
So if you're using PCI passthrough for PV, just keep using normal PV.
Regards,
Anthony Liguori
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
eeded because even with loglvl=none, the banner
is still printed out.
The QEMU console patch is yet another option which sends the Xen
logging output to the
QEMU log.
Regards,
Anthony Liguori
> ___
> Xen-devel mailing list
> Xen-devel@l
ybrid thing.
>
> As in I didn't see any libxl patches, or hvmloader or any of that
> that would 'slurp' this up and make the 'xl create' work out of the box
> so that PV guests are booted as HVM.
>
> Or does the admin have to do some of the 'migration&
ity-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
>
> But this is not a usual situation. This time, we don't have the time
> to wait.
>
> Opinions ?
Whatever solution is chosen, I agree getting a solution merge
On Mon, Jan 8, 2018 at 9:34 AM, Wei Liu wrote:
> On Mon, Jan 08, 2018 at 09:03:44AM -0800, Anthony Liguori wrote:
>> On Mon, Jan 8, 2018 at 8:39 AM, Ian Jackson
>> wrote:
>> > Wei Liu writes ("Re: [Xen-devel] [PATCH 00/22] Vixen: A PV-in-HVM shim"):
>&g
On Mon, Jan 8, 2018 at 9:13 AM, Wei Liu wrote:
> On Sun, Jan 07, 2018 at 12:28:16PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
>> appears to be very difficult to isolate the hyper
On Mon, Jan 8, 2018 at 8:30 AM, Wei Liu wrote:
> On Mon, Jan 08, 2018 at 08:02:07AM -0800, Anthony Liguori wrote:
>> On Mon, Jan 8, 2018 at 4:11 AM, Roger Pau Monné wrote:
>> > On Mon, Jan 08, 2018 at 11:54:57AM +, Wei Liu wrote:
>> >> Hi Anthony
>> &g
On Mon, Jan 8, 2018 at 8:39 AM, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH 00/22] Vixen: A PV-in-HVM shim"):
>> On Mon, Jan 08, 2018 at 08:02:07AM -0800, Anthony Liguori wrote:
>> > OTOH, the HVM version of the series requires no tools changes an
On Jan 8, 2018 8:28 AM, "George Dunlap" wrote:
On Mon, Jan 8, 2018 at 4:02 PM, Anthony Liguori
wrote:
>>> I do want to make the shim be able to run in both pvh and hvm mode
>>> (which doesn't seem to be too hard in practice).
>>
>> AFAIK the pv-shim
On Mon, Jan 8, 2018 at 4:11 AM, Roger Pau Monné wrote:
> On Mon, Jan 08, 2018 at 11:54:57AM +, Wei Liu wrote:
>> Hi Anthony
>>
>> On Sat, Jan 06, 2018 at 02:54:15PM -0800, Anthony Liguori wrote:
>> > From: Anthony Liguori
>> >
>> > CVE-2017-5
On Sun, Jan 7, 2018 at 4:27 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Jan 07, 2018 at 12:28:31PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> This is necessary to trigger event channel upcalls but it is also
>> useful to passthrough the full versio
On Sun, Jan 7, 2018 at 4:22 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Jan 07, 2018 at 12:28:29PM -0800, Anthony Liguori wrote:
>> From: Jan H. Schönherr
>>
>> While the hwdom_shutdown() is able to reboot the system, it fails to
>> properly power it off. With SCHEDO
On Sun, Jan 7, 2018 at 4:18 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Jan 07, 2018 at 12:28:25PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>
> ..snip.
>> diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
>> index c0a81dd..cacbe69 1
From: Anthony Liguori
Our initial approach exposed the console ring directly to guests
which worked well except for the fact that very old versions of Xen
did not support console ring for HVM guests. It also proved to
be complicated from a management tool perspective since both the
serial
From: Jan H. Schönherr
While the hwdom_shutdown() is able to reboot the system, it fails to
properly power it off. With SCHEDOP_shutdown, we delegate the problem.
Signed-off-by: Jan H. Schönherr
---
xen/common/domain.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/com
From: Anthony Liguori
For Vixen, we do not want to pass through all event channel
operations as HVM guests do not have nearly as many event channel
interactions as PV and on older versions of Xen, there is no reliable
way to wake up an event channel on VCPU != 0 leading to a variety of
deadlocks
From: Anthony Liguori
Some older guests special case domid=0 instead of checking the
shared info flags so in order to get PV drivers loaded properly,
we need to make the guest always appear with a domid != 0.
While the Vixen domain is the hardware domain, we don't want it
to behave that w
From: Anthony Liguori
This patch registers an interrupt handler using either an INTx
interrupt from the platform PCI device, CALLBACK_IRQ vector
delivery, or evtchn_upcall_vector depending on what the parent
hypervisor supports.
The event channel polling code comes from Linux but uses the
Signed-off-by: Anthony Liguori
---
v1 -> v2
- adapted for Vixen
---
xen/arch/x86/pv/dom0_build.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index a554629..2bc6339 100644
--- a/xen/arch/x86/pv/dom0_build.c
+
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
xen/arch/x86/guest/Makefile | 1 +
xen/arch/x86/guest/hypercall_page.S | 79 ++
xen/arch/x86/guest/xen.c | 5 ++
xen/arch/x86/xen.lds.S| 1 +
xen/include/asm-x86/guest.h
I sent a v2 out with most of the changes discussed in this thread.
The only things missing are getting rid of hardware_domain and
ECS_RESERVED vs. ECS_PROXY.
Regards,
Anthony Liguori
On Sat, Jan 6, 2018 at 4:05 PM, Anthony Liguori wrote:
> On Sat, Jan 6, 2018 at 3:50 PM, Andrew Coo
From: Matt Wilson
When using Vixen, it is helpful to get the Xen messages in a
separate channel than the console output. Add an option to
output to the QEMU backdoor logging port.
Signed-off-by: Matt Wilson
---
v1 -> v2
- #ifdef for !x86_64
---
xen/drivers/char/console.c | 35 +++
From: Anthony Liguori
Only print the banner if the log threshold is at least info.
For Vixen guests, we want the console output to be exactly what the
PV guest would show on it's own. That means the inner Xen banner
can potentially break automation that assumes a specific type of
co
From: Anthony Liguori
We split initialization of Vixen into two parts. The first part
just detects the presence of an HVM hypervisor so that we can
figure out whether to modify the e820 table.
The later initialization is used to actually map the shared_info
structure from the parent hypervisor
From: Anthony Liguori
This allows for proper accounting of steal time within the guest.
Signed-off-by: Anthony Liguori
---
xen/common/domain.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ede377c..780f8ff 100644
--- a/xen/common
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
xen/arch/x86/Kconfig | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7c45829..07530bf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -117,6 +117,23 @@ c
event channels that are
forwarded to the hypervisor we're running under.
This makes the code more readable in many places.
Signed-off-by: Jan H. Schönherr
Signed-off-by: Anthony Liguori
---
xen/common/event_channel.c | 87 --
xen/include/xen/ev
From: Anthony Liguori
The grant table is a region of guest memory that contains GMFNs
which in PV are MFNs but are PFNs in HVM. Since a Vixen guest MFN
is an HVM PFN, we can pass this table directly through to the outer
Xen which cuts down considerably on overhead.
We do not forward most of
From: Jan H. Schönherr
The function originally did the following unconditionally:
send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
The new variant should reflect the non-Vixen case correctly.
Signed-off-by: Jan H. Schönherr
Signed-off-by: Anthony Liguori
From: Anthony Liguori
Otherwise when time sharing a physical CPU, the calculation can
be bogus resulting in time drift for the guest due to improper
frequency within pvclock.
Signed-off-by: Anthony Liguori
---
xen/arch/x86/guest/vixen.c| 22 ++
xen/arch/x86/time.c
From: Anthony Liguori
The dom0 builder requires a number of modifications in order to be
able to launch unprivileged guests. The console and store pages
must be mapped in a specific location within the guest's initial
page table.
We also have to setup the start info to be what's ex
From: Anthony Liguori
Our intention is for the Vixen guest to be deprivileged so we need
to avoid permitting access to each IRQ even though it is technically
the hardware domain.
Signed-off-by: Anthony Liguori
---
xen/arch/x86/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Anthony Liguori
Vixen (Virtualized Xen) is a paravirtual mode of Xen where
paravirtual I/O is passed through from the parent hypervisor
all the way through the dom0 guest. The dom0 guest is also
deprivileged and renumbered to give the appearance that it
is running as a normal PV guest
From: Anthony Liguori
CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
appears to be very difficult to isolate the hypervisor's page tables
from PV domUs while maintaining ABI compatibility. Instead of trying
to make a KPTI-like approach work for Xen PV, it seems reaso
From: Jan H. Schönherr
Intel says for CPUID leaf 0Bh:
"Software must not use EBX[15:0] to enumerate processor
topology of the system. This value in this field
(EBX[15:0]) is only intended for display/diagnostic
purposes. The actual number of logical processors
available to BIOS/OS/
From: Anthony Liguori
This is necessary to trigger event channel upcalls but it is also
useful to passthrough the full version information such that the
guest believes it is running on the parent Xen.
Signed-off-by: Matt Wilson
Signed-off-by: Anthony Liguori
---
v1 -> v2
- don't pass
From: Anthony Liguori
In order to be able to assign the Xenstore page into the Vixen guest,
we need struct page_info's to exist. We do this by modifying the
e820 table early in boot and then using the badpages handling to
prevent these pages from being added to the xenheap.
Since these
From: Andrew Cooper
Signed-off-by: Andrew Cooper
---
v1 -> v2
- ARM stubs
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/guest/Makefile | 1 +
xen/arch/x86/guest/xen.c| 75 +
xen/arch/x86/setup.c| 4 +++
xen/include/as
On Sun, Jan 7, 2018 at 9:09 AM, Anthony Liguori wrote:
> On Sun, Jan 7, 2018 at 8:45 AM, Andrew Cooper
> wrote:
>> On 07/01/2018 15:42, Anthony Liguori wrote:
>>> On Sun, Jan 7, 2018 at 12:36 AM, Roger Pau Monné
>>> wrote:
>>>> On Sat, Jan 06, 2018
On Sun, Jan 7, 2018 at 8:45 AM, Andrew Cooper wrote:
> On 07/01/2018 15:42, Anthony Liguori wrote:
>> On Sun, Jan 7, 2018 at 12:36 AM, Roger Pau Monné
>> wrote:
>>> On Sat, Jan 06, 2018 at 02:54:31PM -0800, Anthony Liguori wrote:
>>>> static
On Sun, Jan 7, 2018 at 1:02 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:37PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> The dom0 builder requires a number of modifications in order to be
>> able to launch unprivileged guests. The cons
On Sun, Jan 7, 2018 at 12:44 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:33PM -0800, Anthony Liguori wrote:
>> From: Jan H. Schönherr
>>
>> Previously, we would keep proxied event channels as ECS_INTERDOMAIN
>> channel around. This works for most
On Sun, Jan 7, 2018 at 12:42 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:32PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> This patch registers an interrupt handler using either an INTx
>> interrupt from the platform PCI device, CALLBACK
On Sun, Jan 7, 2018 at 12:36 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:31PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> The grant table is a region of guest memory that contains GMFNs
>> which in PV are MFNs but are PFNs in HVM. Since
On Sun, Jan 7, 2018 at 12:31 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:30PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> This is necessary to trigger event channel upcalls but it is also
>
> I'm lost here, what does version ha
On Sun, Jan 7, 2018 at 12:27 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:28PM -0800, Anthony Liguori wrote:
>> From: Jan H. Schönherr
>>
>> While the hwdom_shutdown() is able to reboot the system, it fails to
>> properly power it off. With SCHEDOP_shutdo
On Sun, Jan 7, 2018 at 12:23 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:26PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> We split initialization of Vixen into two parts. The first part
>> just detects the presence of an HVM hypervis
On Sun, Jan 7, 2018 at 12:18 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:25PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> Our intention is for the Vixen guest to be deprivileged so we need
>> to avoid permitting access to each IRQ ev
On Sun, Jan 7, 2018 at 12:16 AM, Roger Pau Monné wrote:
> On Sat, Jan 06, 2018 at 02:54:24PM -0800, Anthony Liguori wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index a56f875..935901b 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x
On Sat, Jan 6, 2018 at 4:06 PM, Matt Wilson wrote:
> On Sat, Jan 06, 2018 at 02:54:22PM -0800, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> Vixen (Virtualized Xen) is a paravirtual mode of Xen where
>> paravirtual I/O is passed through from the parent hyperv
On Sat, Jan 6, 2018 at 2:54 PM, Anthony Liguori wrote:
> From: Matt Wilson
>
> When using Vixen, it is helpful to get the Xen messages in a
> separate channel than the console output. Add an option to
> output to the QEMU backdoor logging port.
>
> Signed-off-by: Matt Wi
On Sat, Jan 6, 2018 at 3:50 PM, Andrew Cooper wrote:
> On 06/01/2018 22:54, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
>> appears to be very difficult to isolate the hypervisor's pa
On Sat, Jan 6, 2018 at 2:54 PM, Anthony Liguori wrote:
> From: Anthony Liguori
>
> CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
> appears to be very difficult to isolate the hypervisor's page tables
> from PV domUs while maintaining ABI compatibility
From: Anthony Liguori
Our intention is for the Vixen guest to be deprivileged so we need
to avoid permitting access to each IRQ even though it is technically
the hardware domain.
Signed-off-by: Anthony Liguori
---
xen/arch/x86/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Anthony Liguori
The grant table is a region of guest memory that contains GMFNs
which in PV are MFNs but are PFNs in HVM. Since a Vixen guest MFN
is an HVM PFN, we can pass this table directly through to the outer
Xen which cuts down considerably on overhead.
We do not forward most of
From: Anthony Liguori
This is necessary to trigger event channel upcalls but it is also
useful to passthrough the full version information such that the
guest believes it is running on the parent Xen.
Signed-off-by: Matt Wilson
Signed-off-by: Anthony Liguori
---
xen/common/kernel.c | 82
From: Anthony Liguori
Our initial approach exposed the console ring directly to guests
which worked well except for the fact that very old versions of Xen
did not support console ring for HVM guests. It also proved to
be complicated from a management tool perspective since both the
serial
From: Anthony Liguori
We split initialization of Vixen into two parts. The first part
just detects the presence of an HVM hypervisor so that we can
figure out whether to modify the e820 table.
The later initialization is used to actually map the shared_info
structure from the parent hypervisor
From: Anthony Liguori
Some older guests special case domid=0 instead of checking the
shared info flags so in order to get PV drivers loaded properly,
we need to make the guest always appear with a domid != 0.
While the Vixen domain is the hardware domain, we don't want it
to behave that w
1 - 100 of 118 matches
Mail list logo
