>>> On 08.01.18 at 17:22, wrote:
> On Mon, Jan 08, 2018 at 09:05:40AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:06, wrote:
>> > +unsigned long evtchn = xchg(&XEN_shared_info->evtchn_pending[l1],
>> > 0);
>> > +
>> > +__clear_bit(l1, &pending);
>> > +evtchn &= ~XE
>>> On 09.01.18 at 01:14, wrote:
> On 08/01/2018 17:45, Ian Jackson wrote:
>> AIUI we have a series for pv-in-pvh shim which is nearing completion
>> in the sense that it will have been well-tested (especially the
>> hypervisor parts) and has good functionality. (Wei is handling the
>> assembly o
>>> On 08.01.18 at 19:24, wrote:
> On 04/01/18 09:23, Jan Beulich wrote:
> On 04.01.18 at 01:15, wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -73,37 +73,58 @@ void (*pv_post_outb_hook)(unsigned int port, u8 value);
>>>
>>> typedef void io_
>>> On 08.01.18 at 20:01, wrote:
> On 04/01/18 09:32, Jan Beulich wrote:
> On 04.01.18 at 01:15, wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -558,8 +558,41 @@ static void init_amd(struct cpuinfo_x86 *c)
>>> wrmsr_amd_safe(0xc001100d, l,
>>> On 04.01.18 at 14:06, wrote:
> +void __init pv_shim_setup_dom(struct domain *d, l4_pgentry_t *l4start,
> + unsigned long va_start, unsigned long store_va,
> + unsigned long console_va, unsigned long
> vphysmap,
> +
>>> On 04.01.18 at 14:06, wrote:
> @@ -125,13 +127,28 @@ void __init pv_shim_setup_dom(struct domain *d,
> l4_pgentry_t *l4start,
> })
> SET_AND_MAP_PARAM(HVM_PARAM_STORE_PFN, si->store_mfn, store_va);
> SET_AND_MAP_PARAM(HVM_PARAM_STORE_EVTCHN, si->store_evtchn, 0);
> +SET_AND_MAP
On Mon, Jan 08, 2018 at 06:49:21AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, wrote:
> > From: Roger Pau Monne
> >
> > Signed-off-by: Roger Pau Monné
> > Signed-off-by: Wei Liu
>
> There being no description at all makes it rather harder to review this
> one. I assume that marking
>>> On 04.01.18 at 14:06, wrote:
> +void hypervisor_resume(void)
> +{
> +/* Reset shared info page. */
> +map_shared_info();
> +
> +/*
> + * Reset vcpu_info. Just clean the mapped bitmap and try to map the vcpu
> + * area again. On failure to map (when it was previously mapped)
I finally have a reliable repro and and it's trivial...
Just try to copy a large file out of a Windows VM to an SMB share (using PV
drivers in the VM). Dom0 goes bang pretty much immediately. I get another BUG
too on another CPU...
[ 1062.422497] [ cut here ]
[ 1062.4225
>>> On 04.01.18 at 14:06, wrote:
> @@ -284,7 +291,16 @@ unsigned long __init dom0_compute_nr_pages(
> * maximum of 128MB.
> */
> if ( nr_pages == 0 )
> -nr_pages = -min(avail / 16, 128UL << (20 - PAGE_SHIFT));
> +{
> +uint64_t rsvd = min
>>> On 04.01.18 at 14:06, wrote:
> From: Roger Pau Monne
>
> So that the guest is not able to deplete the memory pool of the shim
> itself by trying to balloon up.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Could perhaps be consider folding into the previous patch.
Jan
_
This run is configured for baseline tests only.
flight 74130 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74130/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
>>> On 04.01.18 at 14:06, wrote:
> @@ -1303,22 +1320,20 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> break;
>
> -case VCPUOP_up: {
> -bool_t wake = 0;
> -domain_lock(d);
> -if ( !v->is_initialised )
> -
On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> On a similarly pragmatic note: would a variation of Anthony's vixen patch
> series be suitable for pre-PVH Xen 4.6 - 4.9? These versions are currently
> documented as security-supported (Oct 2018 - July 2020).
Hmm, Ian's mail seems to be fo
>>> On 04.01.18 at 14:06, wrote:
> @@ -814,6 +817,113 @@ long pv_shim_cpu_down(void *data)
> return 0;
> }
>
> +static unsigned long batch_memory_op(int cmd, struct page_list_head *list)
unsigned int cmd, const struct ...
> +{
> +struct xen_memory_reservation xmr = {
> +.domi
>>> On 04.01.18 at 14:06, wrote:
> From: Roger Pau Monne
>
> shim_mem will now account for both the memory used by the hypervisor
> loaded in memory and the free memory slack given to the shim for
> runtime usage.
>
> From experimental testing it seems like the total amount of MiB used
> by the
Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as
4.10.1"):
> Does this sound fair?
Everything is on fire. Your proposal seems much less radical than
mine. I doubt it will produce a release to our users tomorrow, let
alone this week.
If we can't get agreement to commit
>>> On 04.01.18 at 14:06, wrote:
> From: Roger Pau Monne
>
> When running a 32bit kernel as Dom0 on a 64bit hypervisor the
> hypervisor will try to shrink the hypervisor hole to the minimum
> needed, and thus requires the Dom0 to use XENMEM_machphys_mapping in
> order to fetch the position of th
>>> On 04.01.18 at 14:06, wrote:
> From: Roger Pau Monne
>
> All guest shutdown operations are forwarded to L0, so the only native
> calls to machine_restart happen from crash related paths inside the
> hypervisor, hence switch the reboot code to instead issue a crash
> shutdown.
>
> Signed-off
Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as
4.10.1"):
> What I mean by this is
> that, if we agree to go along this route, patches should be committed to
> staging then immediately cherrypicked to staging-4.10, rather than
> committed to staging-4.10 directly. This e
On 01/09/2018 10:53 AM, Ian Jackson wrote:
> Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as
> 4.10.1"):
>> What I mean by this is
>> that, if we agree to go along this route, patches should be committed to
>> staging then immediately cherrypicked to staging-4.10, rather
George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as
4.10.1"):
> On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > And as my other mail suggests, I don't think we should allow this work
> > to be blocked by outstanding reviewed. IMO we should ship what we
> > have ASAP.
>
> We
>>> On 04.01.18 at 14:06, wrote:
> From: Roger Pau Monne
>
> Since the shim VCPUOP_{up/down} hypercall is wired to the plug/unplug
> of CPUs to the shim itself, start the shim DomU with only the BSP
> online, and let the guest bring up other CPUs as it needs them.
>
> Signed-off-by: Roger Pau M
>>> On 09.01.18 at 10:25, wrote:
> On Mon, Jan 08, 2018 at 06:49:21AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:06, wrote:
>> > +void __init hypervisor_init_memory(void)
>> > +{
>> > +uint64_t pfn = 0;
>> > +long rc;
>> > +
>> > +if ( !xen_guest )
>> > +return;
>> > +
On 09/01/18 08:36, Jan Beulich wrote:
static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8
opcode,
unsigned int port, unsigned int
bytes)
{
+struct stubs *this_stubs = &this_cpu(stubs);
+uns
On Tue, Jan 09, 2018 at 04:03:25AM -0700, Jan Beulich wrote:
> >>> On 09.01.18 at 10:25, wrote:
> > On Mon, Jan 08, 2018 at 06:49:21AM -0700, Jan Beulich wrote:
> >> >>> On 04.01.18 at 14:06, wrote:
> >> > +void __init hypervisor_init_memory(void)
> >> > +{
> >> > +uint64_t pfn = 0;
> >> > +
On Mon, Nov 20, 2017 at 3:44 PM, Oleksandr Grytsov wrote:
> On Tue, Nov 14, 2017 at 2:38 PM, Oleksandr Grytsov
> wrote:
>
>> On Wed, Nov 1, 2017 at 5:04 PM, Oleksandr Grytsov
>> wrote:
>>
>>> From: Oleksandr Grytsov
>>>
>>> This patch set adds PV sound device support to xl.cfg and xl.
>>> See
On Mon, Nov 20, 2017 at 3:44 PM, Oleksandr Grytsov wrote:
> On Tue, Nov 14, 2017 at 2:39 PM, Oleksandr Grytsov
> wrote:
>
>> On Wed, Nov 1, 2017 at 5:05 PM, Oleksandr Grytsov
>> wrote:
>>
>>> From: Oleksandr Grytsov
>>>
>>> Changes since initial:
>>> * add setting backend-type to xenstore
>>>
On Thu, Dec 14, 2017 at 4:14 PM, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> We have following arm-based setup:
>
> - Dom0 with xen and xen tools;
> - Dom1 with device backends (but it is not the driver domain);
> - Dom2 with device frontend;
>
> On Dom2 destroying we have timeout err
On 04/01/18 09:40, Jan Beulich wrote:
On 04.01.18 at 01:15, wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -245,6 +245,20 @@ and not running softirqs. Reduce this if softirqs are
>> not being run frequently
>> enough. Setting this to a
On Thu, Jan 04, 2018 at 12:15:54AM +, Andrew Cooper wrote:
> With all infrastructure in place, it is now safe to let guests see and use
> these features. Allow AMD's IBPB to be set even on Intel hardware, so the
> toolstack can express "IBPB only" to guests.
>
> This also requires updating th
On 04/01/18 09:52, Jan Beulich wrote:
>
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>> uint64_t *val)
>> case MSR_SPEC_CTRL:
>> if ( !cp->feat.ibrsb )
>> goto gp_fault;
>> -*va
On Mon, Jan 08, 2018 at 06:21:04AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, wrote:
> > +long rc;
> > +
> > +if ( !vcpu_info )
> > +{
> > +this_cpu(vcpu_info) = &XEN_shared_info->vcpu_info[vcpu];
> > +return 0;
> > +}
> > +
> > +if ( test_bit(vcpu, v
If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.
Signed-off-by: Ross Lagerwall
---
drivers/xen/gntdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 57efbd3..d3391
When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.
T
flight 117721 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 115643
test-amd64-amd64-xl
On Tue, Jan 09, 2018 at 01:24:02AM -0700, Jan Beulich wrote:
> >>> On 09.01.18 at 01:14, wrote:
> > On 08/01/2018 17:45, Ian Jackson wrote:
> >> AIUI we have a series for pv-in-pvh shim which is nearing completion
> >> in the sense that it will have been well-tested (especially the
> >> hypervisor
flight 74142 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74142/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i
>>> On 09.01.18 at 12:23, wrote:
> On 09/01/18 08:36, Jan Beulich wrote:
> static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8
> opcode,
>unsigned int port, unsigned
> int
> bytes)
> {
> +struct stubs *thi
>>> On 09.01.18 at 12:44, wrote:
> On 04/01/18 09:40, Jan Beulich wrote:
> On 04.01.18 at 01:15, wrote:
>>> +else
>>> +{
>>> +/*
>>> + * Evaluate the safest Branch Target Injection mitigations to use.
>>> + * First, begin with compiler-aided mitigations.
>>> +
>>> On 09.01.18 at 13:03, wrote:
> On 04/01/18 09:52, Jan Beulich wrote:
>>
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>> @@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>>> uint64_t *val)
>>> case MSR_SPEC_CTRL:
>>> if ( !cp->feat.ibrsb )
>>>
On 09/01/18 13:24, Jan Beulich wrote:
On 09.01.18 at 12:44, wrote:
>> On 04/01/18 09:40, Jan Beulich wrote:
>> On 04.01.18 at 01:15, wrote:
+else
+{
+/*
+ * Evaluate the safest Branch Target Injection mitigations to use.
+ * First,
>>> On 09.01.18 at 12:26, wrote:
> On Tue, Jan 09, 2018 at 04:03:25AM -0700, Jan Beulich wrote:
>> >>> On 09.01.18 at 10:25, wrote:
>> > On Mon, Jan 08, 2018 at 06:49:21AM -0700, Jan Beulich wrote:
>> >> >>> On 04.01.18 at 14:06, wrote:
>> >> > +void __init hypervisor_init_memory(void)
>> >> > +
On 09/01/18 13:28, Jan Beulich wrote:
On 09.01.18 at 13:03, wrote:
>> On 04/01/18 09:52, Jan Beulich wrote:
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
uint64_t *val)
case MSR_SPEC_CTR
On Mon, Jan 08, 2018 at 09:42:54AM -0700, Jan Beulich wrote:
> >>> On 08.01.18 at 16:59, wrote:
> > On Fri, Jan 05, 2018 at 04:39:33AM -0700, Jan Beulich wrote:
> >> >>> On 04.01.18 at 14:05, wrote:
> >> > --- a/xen/arch/x86/Makefile
> >> > +++ b/xen/arch/x86/Makefile
> >> > @@ -75,6 +75,8 @@ efi
>>> On 09.01.18 at 14:34, wrote:
> On 09/01/18 13:28, Jan Beulich wrote:
> On 09.01.18 at 13:03, wrote:
>>> On 04/01/18 09:52, Jan Beulich wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
> uint
On Jan 9, 2018 2:59 AM, "Ian Jackson" wrote:
George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as
4.10.1"):
> On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > And as my other mail suggests, I don't think we should allow this work
> > to be blocked by outstanding reviewed. IMO
On Tue, Jan 09, 2018 at 06:08:53AM -0800, Anthony Liguori wrote:
> On Jan 9, 2018 2:59 AM, "Ian Jackson" wrote:
>
> George Dunlap writes ("Re: Radical proposal: ship not-fully-tidied shim as
> 4.10.1"):
> > On 01/09/2018 10:53 AM, Ian Jackson wrote:
> > > And as my other mail suggests, I don't th
On 04/01/18 09:59, Jan Beulich wrote:
On 04.01.18 at 01:15, wrote:
>> Signed-off-by: Andrew Cooper
> Fundamentally (as before)
> Reviewed-by: Jan Beulich
> However:
>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2027,6 +2027,25 @@ int domain_relinquish_resources(stru
Otherwise they are not freed after the kernel proper init.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c |3 +++
drivers/firmware/efi/libstub/secureboot-core.c | 12 ++--
drivers/firmware/efi/libstub/secureboot.c |3 +++
3 files changed, 12
Hi,
Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
may not even know that it runs on secure boot enabled platform.
Daniel
arch/x86/xen/Makefile |4 +++-
arch/x86/xen/efi.c | 14 +
drivers/firmware/e
We have to call efi_get_secureboot() from early Xen dom0 boot code to properly
initialize boot_params.secure_boot. Sadly it lives in the EFI stub. Hence, it is
not readily reachable from the kernel proper. So, move efi_get_secureboot() to
separate file which can be included from the core kernel cod
Otherwise the kernel reports incorrect UEFI secure boot state in the Xen dom0.
By the way fix CFLAGS_mmu_pv.o assignment alignment.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/Makefile |4 +++-
arch/x86/xen/efi.c| 11 +++
2 files changed, 14 insertions(+), 1 deletion(-)
diff
This may help compiler to do some function call optimization.
This is rather cosmetic. If you like this patch apply.
If you do not you may ignore it.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c |2 +-
drivers/firmware/efi/libstub/secureboot-core.c |2 +
Carve out the TSS initialization from load_system_tables().
Signed-off-by: Juergen Gross
---
xen/arch/x86/cpu/common.c| 56
xen/include/asm-x86/system.h | 1 +
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/cpu/comm
As a preparation for doing page table isolation in the Xen hypervisor
in order to mitigate "Meltdown" use dedicated stacks for 64 bit PV
domains mapped to the per-domain virtual area. The TSS is added to
that area, too, and the GDT is no longer a remapped version of the
per physical cpu one.
This
Instead of open coding the calculation of the stack guard page multiple
times add a helper to do the calculation.
Signed-off-by: Juergen Gross
---
xen/arch/x86/mm.c| 8 ++--
xen/include/asm-x86/mm.h | 6 ++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x
Instead of using the TSS and stacks of the physical processor allocate
them per vcpu, map them in the per domain area, and use those.
Signed-off-by: Juergen Gross
---
xen/arch/x86/domain.c| 45 +++
xen/arch/x86/pv/domain.c | 72
Split up context_switch() to prepare switching of the used stack.
Signed-off-by: Juergen Gross
---
xen/arch/x86/domain.c | 67 ---
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d
>>> On 09.01.18 at 15:21, wrote:
> On 04/01/18 09:59, Jan Beulich wrote:
> On 04.01.18 at 01:15, wrote:
>>> Signed-off-by: Andrew Cooper
>> Fundamentally (as before)
>> Reviewed-by: Jan Beulich
>> However:
>>
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -2027,6 +20
On Thu, Jan 04, 2018 at 01:05:43PM +, Wei Liu wrote:
> Instead, special case GRUB1 rather assuming that all bootloaders except GRUB2
> need a parameter stripping.
The FreeBSD loader also prepends "xen.gz" (or the Xen kernel filename)
to the command line. Hence this change will break it.
Roger
On Tue, Jan 9, 2018 at 2:49 AM, Ian Jackson wrote:
> Andrew Cooper writes ("Re: Radical proposal: ship not-fully-tidied shim as
> 4.10.1"):
>> Does this sound fair?
>
> Everything is on fire. Your proposal seems much less radical than
> mine. I doubt it will produce a release to our users tomor
Since it's already rc7:
"Give me a subtle ping, Vasili. One subtle ping only, please."
On 04/01/18 21:02, Sander Eikelenboom wrote:
> On 04/01/18 12:44, Juergen Gross wrote:
>> On 04/01/18 11:17, Sander Eikelenboom wrote:
>>> Hi Boris / Juergen,
>>>
>>> First of all best wishes for a quite turbule
On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
> > > > On 04.01.18 at 14:06, wrote:
> > +size_t consoled_guest_rx(void)
> > +{
> > +size_t recv = 0, idx = 0;
> > +XENCONS_RING_IDX cons, prod;
> > +
> > +if ( !cons_ring )
> > +return 0;
> > +
> > +spin_lock(&rx_lock);
On Mon, Jan 08, 2018 at 07:06:14AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, wrote:
> > From: Roger Pau Monne
> > --- a/xen/arch/x86/pv/dom0_build.c
> > +++ b/xen/arch/x86/pv/dom0_build.c
> > @@ -31,9 +31,8 @@
> > #define L3_PROT (BASE_PROT|_PAGE_DIRTY)
> > #define L4_PROT (BASE_PRO
On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote:
>On 01/07/2018 11:01 PM, Chao Gao wrote:
>> Define interface, structures and hypercalls for toolstack to build
>> cpu topology and for guest that will retrieve it [1].
>> Two subop hypercalls introduced by this patch:
>> XEN_DOMCTL_se
On 09/01/18 16:29, Sander Eikelenboom wrote:
> Since it's already rc7:
> "Give me a subtle ping, Vasili. One subtle ping only, please."
I like that film :-)
Pavel, can you please comment? Do you have an idea how to repair the
issue or should we revert your patch in 4.15?
Juergen
>
> On 04/01/
Hi Juergen,
Do you have this patch applied:
https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be
Thank you,
Pavel
On 01/09/2018 11:10 AM, Juergen Gross wrote:
On 09/01/18 16:29, Sander Eikelenboom wrote:
Since it's already rc7:
"Give me a subtle ping, Vasili. One
>>> On 08.01.18 at 17:07, wrote:
> On Mon, 8 Jan 2018, Jan Beulich wrote:
> On 07.01.18 at 13:34, wrote:
>>> (XEN) [ Xen-4.10.0-vgpu x86_64 debug=n Not tainted ]
>>
>> The -vgpu tag makes me wonder whether you have any patches in
>> your tree on top of plain 4.10.0 (or 4.10-stagin
>>> On 09.01.18 at 17:09, wrote:
> On Mon, Jan 08, 2018 at 07:06:14AM -0700, Jan Beulich wrote:
>> >>> On 04.01.18 at 14:06, wrote:
>> > From: Roger Pau Monne
>> > --- a/xen/arch/x86/pv/dom0_build.c
>> > +++ b/xen/arch/x86/pv/dom0_build.c
>> > @@ -31,9 +31,8 @@
>> > #define L3_PROT (BASE_PROT|_
>>> On 09.01.18 at 16:43, wrote:
> On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
>> > > > On 04.01.18 at 14:06, wrote:
>> > +size_t consoled_guest_rx(void)
>> > +{
>> > +size_t recv = 0, idx = 0;
>> > +XENCONS_RING_IDX cons, prod;
>> > +
>> > +if ( !cons_ring )
>> > +r
On Mon, Jan 08, 2018 at 07:17:16AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, wrote:
> > @@ -576,11 +578,11 @@ static void noinline init_done(void)
> >
> > system_state = SYS_STATE_active;
> >
> > +domain_unpause_by_systemcontroller(dom0);
> > +
> > /* MUST be done pri
On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote:
> > +module_t *mod;
> > +unsigned int i;
> > +
> > +ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE);
> > +
> > +/*
> > + * Turn hvm_start_info into mbi. Luckily all modules are placed under
> > 4GB
> > + * bo
On 09/01/18 17:16, Pavel Tatashin wrote:
> Hi Juergen,
>
> Do you have this patch applied:
>
> https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be
Seems this hasn't made it to Linus yet ?
I will give it a test and report back, thanks !
>
> Thank you,
> Pavel
>
>
On 01/09/2018 11:31 AM, Sander Eikelenboom wrote:
> On 09/01/18 17:16, Pavel Tatashin wrote:
>> Hi Juergen,
>>
>> Do you have this patch applied:
>>
>> https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be
> Seems this hasn't made it to Linus yet ?
>
> I will give it a t
>>> On 09.01.18 at 16:45, wrote:
> On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote:
>> > +pvh_mbi.mods_count = pvh_info->nr_modules;
>> > +pvh_mbi.mods_addr = __pa(pvh_mbi_mods);
>> > +
>> > +mod = pvh_mbi_mods;
>> > +entry = __va(pvh_info->modlist_paddr);
>>
>> How co
The opcode potentially written into ctxt->io_emul_stub[] in the case
that ioemul_handle_quirk() is overriding the default logic isnt
accounted for in the build-time check that the stubs are large enough.
Introduce IOEMUL_QUIRK_STUB_BYTES and use for both the main and quirk
stub cases. As a slim o
On Tue, Jan 09, 2018 at 01:00:10AM -0700, Jan Beulich wrote:
> >>> On 08.01.18 at 17:22, wrote:
> > On Mon, Jan 08, 2018 at 09:05:40AM -0700, Jan Beulich wrote:
> >> >>> On 04.01.18 at 14:06, wrote:
> >> > +unsigned long evtchn =
> >> > xchg(&XEN_shared_info->evtchn_pending[l1], 0);
> >>
On Tue, 9 Jan 2018, George Dunlap wrote:
> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> > On a similarly pragmatic note: would a variation of Anthony's vixen patch
> > series be suitable for pre-PVH Xen 4.6 - 4.9? These versions are currently
> > documented as security-supported (Oct 2
On 09/01/18 14:27, Juergen Gross wrote:
> Instead of using the TSS and stacks of the physical processor allocate
> them per vcpu, map them in the per domain area, and use those.
>
> Signed-off-by: Juergen Gross
I don't see anything here which updates the fields in the TSS across
context switch.
Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
able to run PVH kernels to switch their PV guests directly to PVH
guests; and second, eventually enable the backport of patches which
will enable transparent chan
On Tue, Jan 09, 2018 at 09:41:51AM -0700, Jan Beulich wrote:
> >>> On 09.01.18 at 16:45, wrote:
> > On Fri, Jan 05, 2018 at 06:32:56AM -0700, Jan Beulich wrote:
> >> > +pvh_mbi.mods_count = pvh_info->nr_modules;
> >> > +pvh_mbi.mods_addr = __pa(pvh_mbi_mods);
> >> > +
> >> > +mod = pvh
On 01/09/2018 04:06 AM, Chao Gao wrote:
On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote:
On 01/07/2018 11:01 PM, Chao Gao wrote:
Define interface, structures and hypercalls for toolstack to build
cpu topology and for guest that will retrieve it [1].
Two subop hypercalls introduc
On 09/01/18 17:38, Boris Ostrovsky wrote:
> On 01/09/2018 11:31 AM, Sander Eikelenboom wrote:
>> On 09/01/18 17:16, Pavel Tatashin wrote:
>>> Hi Juergen,
>>>
>>> Do you have this patch applied:
>>>
>>> https://github.com/torvalds/linux/commit/e8c24773d6b2cd9bc8b36bd6e60beff599be14be
>> Seems this h
On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
wrote:
> On Tue, 9 Jan 2018, George Dunlap wrote:
>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch
>> > series be suitable for pre-PVH Xen 4.6 - 4.9? These ver
>>> On 09.01.18 at 18:23, wrote:
> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> wrote:
>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
>>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch
> series be suitable
On 09/01/18 18:01, Andrew Cooper wrote:
> On 09/01/18 14:27, Juergen Gross wrote:
>> Instead of using the TSS and stacks of the physical processor allocate
>> them per vcpu, map them in the per domain area, and use those.
>>
>> Signed-off-by: Juergen Gross
>
> I don't see anything here which upda
>>> On 09.01.18 at 17:45, wrote:
> On Tue, Jan 09, 2018 at 01:00:10AM -0700, Jan Beulich wrote:
>> >>> On 08.01.18 at 17:22, wrote:
>> > On Mon, Jan 08, 2018 at 09:05:40AM -0700, Jan Beulich wrote:
>> >> >>> On 04.01.18 at 14:06, wrote:
>> >> > +unsigned long evtchn =
>> >> > xchg(&XEN_
On Tue, Jan 9, 2018 at 9:33 AM, Jan Beulich wrote:
On 09.01.18 at 18:23, wrote:
>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>> wrote:
>>> On Tue, 9 Jan 2018, George Dunlap wrote:
On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> On a similarly pragmatic note: would
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.
>>
>> Signed-off-by: Anthony Liguori
>>
On 1/9/18 11:33 AM, Jan Beulich wrote:
On 09.01.18 at 18:23, wrote:
>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>> wrote:
>>> On Tue, 9 Jan 2018, George Dunlap wrote:
On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> On a similarly pragmatic note: would a variation of
On 1/8/18 3:44 PM, Anthony Liguori wrote:
>
> 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
On Tue, 9 Jan 2018, Doug Goldstein wrote:
> On 1/9/18 11:33 AM, Jan Beulich wrote:
> On 09.01.18 at 18:23, wrote:
> >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> >> wrote:
> >>> On Tue, 9 Jan 2018, George Dunlap wrote:
> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> >
On 1/9/18 5:50 AM, Wei Liu wrote:
>
> We haven't tested booting the series I posted in HVM mode, but off the
> top of my head it should work in HVM mode as well -- the multiboot path
> is left intact.
>
Can we actually do this before committing to this series? I've seen a
number of "this should
On Tue, Jan 09, 2018 at 09:23:03AM -0800, Anthony Liguori wrote:
> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
> wrote:
> > On Tue, 9 Jan 2018, George Dunlap wrote:
> >> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud wrote:
> >> > On a similarly pragmatic note: would a variation of Anthony's
On Tue, Jan 09, 2018 at 11:59:01AM -0600, Doug Goldstein wrote:
> On 1/9/18 5:50 AM, Wei Liu wrote:
> >
> > We haven't tested booting the series I posted in HVM mode, but off the
> > top of my head it should work in HVM mode as well -- the multiboot path
> > is left intact.
> >
>
> Can we actual
On 1/8/18 11:45 AM, Ian Jackson wrote:
> But this is not a usual situation. This time, we don't have the time
> to wait.
>
> Opinions ?
I'm going to follow up with a top post with my feelings and from info on
various parts of the thread.
We have 2 versions of PV shim, the Citrix version and the
On 01/09/2018 06:13 PM, Doug Goldstein wrote:
> On 1/8/18 11:45 AM, Ian Jackson wrote:
>> But this is not a usual situation. This time, we don't have the time
>> to wait.
>>
>> Opinions ?
>
> I'm going to follow up with a top post with my feelings and from info on
> various parts of the thread.
>
>> On Jan 9, 2018, at 12:56, Stefano Stabellini wrote:
>>
>> On Tue, 9 Jan 2018, Doug Goldstein wrote:
>> On 1/9/18 11:33 AM, Jan Beulich wrote:
>> On 09.01.18 at 18:23, wrote:
On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
wrote:
>>> On Tue, 9 Jan 2018, George Dunlap wrot
On Mon, Jan 08, 2018 at 10:19:39AM -0700, Jan Beulich wrote:
> >>> On 04.01.18 at 14:06, wrote:
> > @@ -30,11 +31,17 @@
> > #include
> > #include
> >
> > +#include
>
> Interesting: The event channel patch gave me the impression that
> it is not intended to deal with 32-bit guests.
AFAICT
1 - 100 of 155 matches
Mail list logo
