ond bit for STIBP. AMD are introducing IPBP only, so enumerate it with
>> a
>> separate bit.
>
> s/IPBP/IBPB/ no? Still getting caught up here so I could certainly be wrong.
IBPB is indeed right.
Regards,
Anthony Liguori
> --
> Doug Goldstein
>
>
>
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
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
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
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
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
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
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
Signed-off-by: Anthony Liguori
---
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
From: Andrew Cooper
Signed-off-by: Andrew Cooper
Signed-off-by: Anthony Liguori
---
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
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| 21 +
xen/arch/x86/time.c
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: 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
Signed-off-by: Anthony Liguori
---
xen/common/domain.c | 14 ++
1 file changed, 14
From: Andrew Cooper
Signed-off-by: Andrew Cooper
Signed-off-by: Anthony Liguori
---
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
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
Signed-off-by: Anthony Liguori
---
xen/drivers/char/console.c | 24
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
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
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
stead, which is
intended for that.
Signed-off-by: Jan H. Schönherr
Signed-off-by: Anthony Liguori
---
xen/arch/x86/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index e9588b3..22f392f 100644
--- a/x
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
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: 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 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 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 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: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: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: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: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: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: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 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 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 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
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: 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
---
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
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
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
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: 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: 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
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: 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
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: 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
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: 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
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
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: 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
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
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
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: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 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 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 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 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 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 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
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
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&
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
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
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
;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
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
>
>> 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
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.
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
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
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: 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: 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
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
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
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: 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
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
1 - 100 of 118 matches
Mail list logo
