flight 104199 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104199/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104179
test-armhf-armhf-libvirt-qcow2 1
Hi all,
Recently, I’ve been trying to modify netback.c to print network data that is
going into the VM. For example, I’m doing an SSL handshake with the VM as the
server, and I send the following hexadecimal string from the client to the VM:
160302002f012b03026161616161616161616161616161616
flight 104198 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104198/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2b631390f9f5f6971c3c8a7f0f47160b80cf072b
baseline version:
ovmf 13a50a6fe1dcfa6600c38
flight 104191 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104191/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3)broken REGR. vs. 1041
On 16/01/17 19:40, Stefano Stabellini wrote:
> On Mon, 16 Jan 2017, Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: STAO spec in xen.git"):
>>> In that case, I think we should still commit it as ODT, but convert it
>>> automatically to PDF when we publish it (we do something similar with
>>>
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces struct hvm_pi_ops, which is declared in struct hvm_domain.
Signed-off-by: Suravee Suthikulpanit
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Konrad Rzeszu
Also, I just noticed another suggestion from Boris to change
the hvm_domain.pi_ops to a pointer instead. So, I will be sending out V6.
Thanks,
Suravee
On 1/17/17 09:35, Suravee Suthikulpanit wrote:
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used
Hi all,
Recently, I’ve been trying to modify netback.c to print network data that is
going into the VM. For example, I’m doing an SSL handshake with the VM as the
server, and I send the following hexadecimal string from the client to the VM:
160302002f012b03026161616161616161616161616161616
flight 104196 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104196/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 13a50a6fe1dcfa6600c38456ee24e0f9ecf51b5f
baseline version:
ovmf 4d5c1d50d87201b0a0e69
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces the struct hvm_pi_ops in the struct hvm_domain to hold them.
Signed-off-by: Suravee Suthikulpanit
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Konrad Rzes
GRR... sorry again for confusion. Sending error.
Please ignore version4. I'll send out V5 instead then.
Suravee
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi all,
Recently, I’ve been trying to modify netback.c to print network data that is
going into the VM. For example, I’m doing an SSL handshake with the VM as the
server, and I send the following hexadecimal string from the client to the VM:
160302002f012b03026161616161616161616161616161616
From 2b8e159039e3e70414d49932e558b0d26b44be11 Mon Sep 17 00:00:00 2001
From: Suravee Suthikulpanit
Date: Sat, 17 Sep 2016 01:19:49 -0500
Subject: [PATCH V4] x86/HVM: Introduce struct hvm_pi_ops
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces the struct hvm_pi_ops in the struct hvm_domain to hold them.
Signed-off-by: Suravee Suthikulpanit
Cc: Andrew Cooper
Cc: Konrad Rzeszutek Wilk
Cc: B
Hi Shaohua,
I've made some new little tests, maybe it can help.
- I tried creating the RAID 5 stack with only 2 drives (mdadm --create
/dev/md10 --raid-devices=3 --level=5 /dev/sdc1 /dev/sdd1 missing).
The same issue is happening.
- but one time (still with 2/3 drives), I was not able to crash
flight 104195 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104195/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 104189 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104189/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm3 host-install(3)broken REGR. vs. 104163
build
On Mon, 16 Jan 2017, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Signed-off-by: Andrii Anisov
Thanks for the patch!
> arch/arm/xen/mm.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index ff812a2..dc83a35 100644
> --- a/arch
On Mon, 16 Jan 2017, Juergen Gross wrote:
> On 13/01/17 19:44, Boris Ostrovsky wrote:
> > On 01/13/2017 01:26 PM, Stefano Stabellini wrote:
> >> On Fri, 13 Jan 2017, Boris Ostrovsky wrote:
> >>> On 01/12/2017 04:39 PM, Stefano Stabellini wrote:
> The following commit:
>
> commit 72a9
flight 104194 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104194/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3)broken REGR. vs.
On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> On 14.01.17 at 03:52, wrote:
>>> On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
In a native situation, SMAP raises #PF if hardware tries to follow a
On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> >>> On 14.01.17 at 03:52, wrote:
> > On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
> >> In a native situation, SMAP raises #PF if hardware tries to follow a
> >> user pointer outside of an area whitelisted by the kerne
On Mon, 16 Jan 2017, Stefano Stabellini wrote:
> On Mon, 16 Jan 2017, Andrii Anisov wrote:
> > From: Stefano Stabellini
> >
> > This function creates userspace mapping for the DMA-coherent memory.
> >
> > Signed-off-by: Stefano Stabellini
> > Signed-off-by: Oleksandr Dmytryshyn
> > Signed-off-
On Mon, 16 Jan 2017, Andrii Anisov wrote:
> From: Stefano Stabellini
>
> This function creates userspace mapping for the DMA-coherent memory.
>
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Andrii Anisov
> ---
> arch/arm/xen/mm.c | 14
flight 104193 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104193/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3)broken REGR. vs.
On Mon, 16 Jan 2017, Julien Grall wrote:
> Hi Jan,
>
> On 09/01/17 08:40, Jan Beulich wrote:
> > > > > On 07.01.17 at 07:05, wrote:
> > > Question: Why this address is not mapped?. If mapped where this va is
> > > mapped?.
> >
> > Well, I think this is the wrong question to ask. Why would it be
On 1/16/17 8:04 AM, Andrew Cooper wrote:
> The chageset/version/compile information is currently exported as a set of
> function calls into a separate translation unit, which is inefficient for all
> callers.
>
> Replace the function calls with externs pointing appropriately into .rodata,
> which
flight 104188 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104188/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3)broken REGR. vs. 104179
bu
On Mon, 16 Jan 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/01/17 19:27, Stefano Stabellini wrote:
> > On Wed, 28 Dec 2016, Julien Grall wrote:
> > > On 20/12/16 22:33, Stefano Stabellini wrote:
> > > > On Tue, 20 Dec 2016, Julien Grall wrote:
> > > > > On 20/12/2016 00:54, Stefano Stabellini
On Mon, 16 Jan 2017, André Przywara wrote:
> On 13/01/17 19:37, Stefano Stabellini wrote:
> > On Thu, 12 Jan 2017, Andre Przywara wrote:
>
> Hi Stefano,
>
> ...
>
> +list_for_each_entry(lpi_irq, &v->arch.vgic.pending_lpi_list, entry)
> +{
> +if ( lpi_irq->pirq.irq
On Mon, 16 Jan 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 03/01/17 22:51, Stefano Stabellini wrote:
> > On Wed, 28 Dec 2016, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 22/12/16 02:15, Stefano Stabellini wrote:
> > > > gic_update_one_lr is called with the vgic lock held, but it calls
Hi Jan,
On 09/01/17 08:40, Jan Beulich wrote:
On 07.01.17 at 07:05, wrote:
Question: Why this address is not mapped?. If mapped where this va is
mapped?.
Well, I think this is the wrong question to ask. Why would it be mapped
if there's no memory there?
(XEN) Walking Hypervisor VA 0x847fff
On Mon, 16 Jan 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: STAO spec in xen.git"):
> > In that case, I think we should still commit it as ODT, but convert it
> > automatically to PDF when we publish it (we do something similar with
> > the markdown docs, converting them from markdown
On Mon, 16 Jan 2017, Andrew Cooper wrote:
> The chageset/version/compile information is currently exported as a set of
> function calls into a separate translation unit, which is inefficient for all
> callers.
>
> Replace the function calls with externs pointing appropriately into .rodata,
> which
On Mon, 16 Jan 2017, Roger Pau Monné wrote:
> On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> > >>> On 16.01.17 at 17:31, wrote:
> > > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> > >> >>> On 16.01.17 at 16:14, wrote:
> > >> > On Fri, Jan 13, 2017 at 08:51:57AM -0
osstest service owner writes ("[xen-unstable test] 104187: trouble:
blocked/broken"):
> flight 104187 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104187/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests w
flight 104187 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104187/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3)broken REGR. vs. 10418
On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 17:31, wrote:
> > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >> >>> On 16.01.17 at 16:14, wrote:
> >> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >> >> >>> On 12.01.17 at 13:
On Fri, Jan 13, 2017 at 02:38:21PM +0100, Juergen Gross wrote:
> On 13/01/17 14:31, Juergen Gross wrote:
> > On 13/01/17 13:18, Wei Liu wrote:
> >> The only place that used such option was removed in 388d3011.
> >>
> >> Signed-off-by: Wei Liu
> >
> > Reviewed-by: Juergen Gross
>
> Sorry, this s
On Mon, Jan 16, 2017 at 10:37:31AM +, Andrew Cooper wrote:
> On 16/01/17 09:41, Wei Liu wrote:
> > CC Andrew and Jan
> >
> > On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote:
> >> Add AVX512 vpopcntdq information in xen-cpuid.c
> >>
> >> Signed-off-by: He Chen
>
> Reviewed-by: Andrew C
On 16/01/17 17:07, Jan Beulich wrote:
On 16.01.17 at 12:40, wrote:
>> Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to
>> offer.
>> For domains which are constructed with disable_migrate set, offer ITSC
>> automatically.
> I'm afraid "constructed" is ambiguous here: To
On 13/01/17 13:20, Jan Beulich wrote:
>
>>> @@ -2235,7 +2241,7 @@ x86_decode(
>>> break;
>>> }
>>> }
>>> -if ( mode_64bit() && !vex.r )
>>> +if ( !vex.r )
>>> rex_prefix |= REX_R;
>>>
>>> On 16.01.17 at 18:07, wrote:
> If we don't want to bake 64-bit pointers into the ABI then I guess a
> compat layer is the only way. Guess I'll go and stare at macros until my
> brain explodes...
Well, before you do I'd really hope for Andrew to provide us (or at
least me, if everyone else
>>> On 16.01.17 at 18:02, wrote:
> On 16/01/17 16:45, Jan Beulich wrote:
> On 16.01.17 at 12:40, wrote:
>>> @@ -154,6 +152,13 @@ struct cpuid_policy
>>> };
>>> uint32_t /* b */:32, xss_low, xss_high;
>>> };
>>> +
>>> +/* Per-component common state.
On 16/01/17 16:58, Jan Beulich wrote:
On 16.01.17 at 12:40, wrote:
>> @@ -1007,10 +864,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>> break;
>>
>> case XSTATE_CPUID:
>> -if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
>> +if ( !p->bas
>>> On 16.01.17 at 12:40, wrote:
> Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to offer.
> For domains which are constructed with disable_migrate set, offer ITSC
> automatically.
I'm afraid "constructed" is ambiguous here: To me, construction means
more than just domain_c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2017 16:17
> To: Andrew Cooper
> Cc: Ian Jackson ; Jennifer Herbert
> ; Paul Durrant ; Wei
> Liu ; xen-de...@lists.xenproject.org; Daniel DeGraaf
>
> Subject: Re: [PATCH v3 1/8] public / x86: Introduce
On 16/01/17 16:45, Jan Beulich wrote:
On 16.01.17 at 12:40, wrote:
>> All data in the xstate union, other than the Da1 feature word, is derived
>> from
>> other state; either feature bits from other words, or layout information
>> which
>> has already been collected by Xen's xstate driver.
>>> On 16.01.17 at 12:40, wrote:
> Xen leaf 4 is HVM-only. Report a lower max_leaf to PV guests, so they don't
> go and investigate a leaf which will return all zeros.
>
> Signed-off-by: Andrew Cooper
Well, if you think it's worth it (we'll have to make this leaf visible
again anyway as soon a
>>> On 16.01.17 at 12:40, wrote:
> @@ -1007,10 +864,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> break;
>
> case XSTATE_CPUID:
> -if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
> +if ( !p->basic.xsave || subleaf >= ARRAY_SIZE(p->xstate.r
Hi Stefano,
On 03/01/17 22:51, Stefano Stabellini wrote:
On Wed, 28 Dec 2016, Julien Grall wrote:
Hi Stefano,
On 22/12/16 02:15, Stefano Stabellini wrote:
gic_update_one_lr is called with the vgic lock held, but it calls
vgic_get_target_vcpu, which tries to obtain the rank lock. This can
caus
>>> On 16.01.17 at 17:31, wrote:
> On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
>> >>> On 16.01.17 at 16:14, wrote:
>> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
>> >> >>> On 12.01.17 at 13:13, wrote:
>> >> > # Introduction
>> >> >
>> >> > One of the design g
On 07/12/16 08:44, Juergen Gross wrote:
> Hi,
>
> today the XS_RESTRICT wire command of Xenstore is supported by
> oxenstored only to drop the privilege of a connection to that of the
> domid given as a parameter to the command.
>
> Using this mechanism with Xenstore running in a stubdom will lea
>>> On 16.01.17 at 12:40, wrote:
> All data in the xstate union, other than the Da1 feature word, is derived from
> other state; either feature bits from other words, or layout information which
> has already been collected by Xen's xstate driver.
>
> Recalculate the xstate information for each p
On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 16:14, wrote:
> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >> >>> On 12.01.17 at 13:13, wrote:
> >> > # Introduction
> >> >
> >> > One of the design goals of PVH is to be able to remove as muc
Hi Stefano,
On 03/01/17 23:30, Stefano Stabellini wrote:
On Wed, 28 Dec 2016, Julien Grall wrote:
On 22/12/16 02:15, Stefano Stabellini wrote:
Always take the vgic lock of the old vcpu. When more than one irq
migration is requested before the first one completes, take the vgic
lock of the olde
>>> On 16.01.17 at 12:40, wrote:
> c/s da62246e4c "x86/xsaves: enable xsaves/xrstors/xsavec in xen" introduced
> setup_xstate_features() to allocate and fill xstate_offsets[] and
> xstate_sizes[].
>
> However, fls() casts xfeature_mask to 32bits which truncates LWP out of the
> calculation. As a
>>> On 16.01.17 at 16:21, wrote:
> BTW, before I generate more verbose && complete debug log, just want to
> update that I also see the following in dom0 (without attempting any
> pass-through to the IGD device)
> But this time the log is not flooding at all. Not sure if this is relevant
> to what
>>> On 16.01.17 at 17:05, wrote:
> On 13/01/17 12:47, Jan Beulich wrote:
>> The kernel already has to parse this structure anyway, and will know the
>> bitness of its userspace process. We could easily (at this point)
>> require the kernel to turn it into the kernels bitness for forwa
>>> On 16.01.17 at 16:15, wrote:
> On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
>
>> >>> On 16.01.17 at 14:43, wrote:
>> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>> >> >>> On 16.01.17 at 10:25, wrote:
>> > The fault log itself is really flooding. With a small 4MB ring buff
>>> On 16.01.17 at 16:14, wrote:
> On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
>> >>> On 12.01.17 at 13:13, wrote:
>> > # Introduction
>> >
>> > One of the design goals of PVH is to be able to remove as much Xen PV
>> > specific
>> > code as possible, thus limiting the number o
On 13/01/17 12:47, Jan Beulich wrote:
> The kernel already has to parse this structure anyway, and will know the
> bitness of its userspace process. We could easily (at this point)
> require the kernel to turn it into the kernels bitness for forwarding on
> to Xen, which covers the
Roger Pau Monné writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't
bootup"):
> Shouldn't this be:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Err, yes, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
>>> On 16.01.17 at 15:52, wrote:
> On 16/01/17 11:36, Jan Beulich wrote:
> On 13.01.17 at 19:48, wrote:
>>> On 13/01/17 15:32, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1355,6 +1355,7 @@ static bool vcpu_has
>>> On 16.01.17 at 15:17, wrote:
> On 16/01/17 13:58, Jan Beulich wrote:
> On 16.01.17 at 14:51, wrote:
>>> Right. What happens in reality is this:
>>>
>>> --- Xen Test Framework ---
>>> Environment: HVM 32bit (No paging)
>>> Test VEX.W matching mode:
>>> andn a5a5, ff00ff00 = 00cc00a5
On Fri, Jan 13, 2017 at 04:27:52PM +, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 =
> can't bootup"):
> > I can give it a try although I have practically no experience with
> > OSSTest. Is there a way to subscribe to notifications for those tests
On Mon, Jan 16, 2017 at 11:26:57AM +, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: STAO spec in xen.git"):
> > In that case, I think we should still commit it as ODT, but convert it
> > automatically to PDF when we publish it (we do something similar with
> > the markdown docs, converti
BTW, before I generate more verbose && complete debug log, just want to
update that I also see the following in dom0 (without attempting any
pass-through to the IGD device)
But this time the log is not flooding at all. Not sure if this is relevant
to what I see from the domU with pci pass-through.
On Mon, Jan 16, 2017 at 09:28:45AM -0500, Doug Goldstein wrote:
> On 1/16/17 9:11 AM, Daniel Kiper wrote:
> > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote:
> >> On 1/16/17 7:50 AM, Daniel Kiper wrote:
> >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote:
> >>> On
On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
> >>> On 16.01.17 at 14:43, wrote:
> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
> >> >>> On 16.01.17 at 10:25, wrote:
> > The fault log itself is really flooding. With a small 4MB ring buffer, I
> > wasn't able to capture how it be
On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13, wrote:
> > # Introduction
> >
> > One of the design goals of PVH is to be able to remove as much Xen PV
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by
> > guests,
>
On 12/01/17 14:58, Paul Durrant wrote:
> The handle type passed to the underlying shadow and hap functions is
> changed for compatibility with the new hypercall buffer.
>
> NOTE: This patch also modifies the type of the 'nr' parameter of
> xc_hvm_track_dirty_vram() from uint64_t to uint32_t.
Hi Stefano,
On 03/01/17 18:03, Stefano Stabellini wrote:
On Mon, 2 Jan 2017, Juergen Gross wrote:
On 28/12/16 01:47, Jiandi An wrote:
Ensure all reserved fields of xatp are zero before making
hypervisor call to XEN in xen_map_device_mmio().
xenmem_add_to_physmap_one() in XEN fails the mapping
On Fri, Jan 13, 2017 at 08:27:30AM -0700, Jan Beulich wrote:
> >>> On 12.01.17 at 20:00, wrote:
> > On 12/01/17 12:13, Roger Pau Monné wrote:
> >> Extra entries are going to be added for each vCPU available to the hardware
> >> domain, up to the maximum number of supported vCPUs. Note that support
On 13/01/17 13:56, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> CC: Paul Durrant
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Jun Nakajima
> CC: Kevin Tian
>
> v2: Break out family/
Anthony PERARD writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> Here, it is downloading pip. There's maybe a way to not make it do that.
> I'll try to find out. But I think more stuff are going to be downloaded,
> all the python packages, via
On 16/01/17 11:36, Jan Beulich wrote:
On 13.01.17 at 19:48, wrote:
>> On 13/01/17 15:32, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1355,6 +1355,7 @@ static bool vcpu_has(
>>> #define vcpu_has_cr8_legacy() vcp
On Thu, Jan 12, 2017 at 07:00:57PM +, Andrew Cooper wrote:
> On 12/01/17 12:13, Roger Pau Monné wrote:
[...]
> > ## QEMU CPU hotplug using ACPI
> >
> > The ACPI tables provided to HVM guests contain processor objects, as
> > created by
> > libacpi. The number of processor objects in the ACPI n
On Mon, Jan 09, 2017 at 06:58:19AM -0800, Luis R. Rodriguez wrote:
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
is
> documentation in a central place and provide helpers to
> build custom Linux secti
On Mon, Jan 16, 2017 at 1:43 PM, G.R. wrote:
> On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>>
>> >>> On 16.01.17 at 10:25, wrote:
>> > Here are some relevant logs, please help comment what's going on here
>> > and
>> > what's the next step of diagnose.
>> > It appears that the fault addr
On 1/16/17 9:11 AM, Daniel Kiper wrote:
> On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote:
>> On 1/16/17 7:50 AM, Daniel Kiper wrote:
>>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote:
>>> On 13.01.17 at 20:21, wrote:
> Doug v1 - fix incorrect assembly (identif
On 16/01/17 13:58, Jan Beulich wrote:
On 16.01.17 at 14:51, wrote:
>> Right. What happens in reality is this:
>>
>> --- Xen Test Framework ---
>> Environment: HVM 32bit (No paging)
>> Test VEX.W matching mode:
>> andn a5a5, ff00ff00 = 00cc00a5
>> Test VEX.W opposite to mode:
>> andn
Today a Xenstore watch event is delivered via a callback function
declared as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
As all watch events only ever come with two parameters (path and token)
changing the prototype to:
void (*callback)(struct
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.
Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xe
The xenbus driver used for communication with Xenstore (all kernel
accesses to Xenstore and in case of Xenstore living in another domain
all accesses of the local domain to Xenstore) is rather simple
especially regarding multiple concurrent accesses: they are just being
serialized in spite of Xenst
This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol
support for EFI platforms'.
- fix incorrect assembly (identified by Andrew Cooper)
- fix issue where the trampoline size was left as 0 and the
way the memory is allocated for the trampolines we would go to
the end of an a
The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.
Clean this up by moving the externally used sym
This is a series based on v11 of Daniel Kiper's
"x86: multiboot2 protocol support" series. It aims to collect up all the
fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in
code review and testing on actual hardware. I've had problems with the
relocation portion of the series
From: Daniel Kiper
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
Reviewed-by: Doug Goldstein
Tested-by: Doug Goldstein
---
Doug v2 - dropped all my changes and moved them into their own patch
Doug
From: Daniel Kiper
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Do
From: Daniel Kiper
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. C
From: Daniel Kiper
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not
On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote:
> On 1/16/17 7:50 AM, Daniel Kiper wrote:
> > On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote:
> > On 13.01.17 at 20:21, wrote:
> >>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
> >>> - fix i
Hi Stefano,
On 03/01/17 19:27, Stefano Stabellini wrote:
On Wed, 28 Dec 2016, Julien Grall wrote:
On 20/12/16 22:33, Stefano Stabellini wrote:
On Tue, 20 Dec 2016, Julien Grall wrote:
On 20/12/2016 00:54, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Julien Grall wrote:
On 16/12/2016 15:49
>>> On 16.01.17 at 14:51, wrote:
> Right. What happens in reality is this:
>
> --- Xen Test Framework ---
> Environment: HVM 32bit (No paging)
> Test VEX.W matching mode:
> andn a5a5, ff00ff00 = 00cc00a5
> Test VEX.W opposite to mode:
> andn a5a5, ff00ff00 = 00cc00a5
> Test result: S
>>> On 16.01.17 at 14:43, wrote:
> On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
>> >>> On 16.01.17 at 10:25, wrote:
>> > Here are some relevant logs, please help comment what's going on here and
>> > what's the next step of diagnose.
>> > It appears that the fault address 0xcfxx falls
On 1/16/17 6:52 AM, Jan Beulich wrote:
On 13.01.17 at 20:21, wrote:
>> From: Daniel Kiper
>>
>> There is a problem with place_string() which is used as early memory
>> allocator. It gets memory chunks starting from start symbol and goes
>> down. Sadly this does not work when Xen is loaded us
On 16/01/17 12:57, Jan Beulich wrote:
On 16.01.17 at 13:43, wrote:
> On 16.01.17 at 12:59, wrote:
>>> On 16/01/17 11:19, Jan Beulich wrote:
>>> On 13.01.17 at 18:40, wrote:
> On 13/01/17 15:31, Jan Beulich wrote:
>> @@ -5866,6 +5879,67 @@ x86_emulate(
>> break;
>>> On 16.01.17 at 14:38, wrote:
> So, what if I generalize and simplify as following:
>
> +/*
> + * This structure defines function hooks to support hardware-assisted
> + * virtual interrupt delivery to guest. (e.g. VMX PI and SVM AVIC).
> + *
> + * These hooks are defined by the underlying arch
Hi all,
Recently, I’ve been trying to modify netback.c to print network data that is
going into the VM. For example, I’m doing an SSL handshake with the VM as the
server, and I send the following hexadecimal string from the client to the VM:
160302002f012b03026161616161616161616161616161616
1 - 100 of 154 matches
Mail list logo
