This run is configured for baseline tests only.
flight 68378 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68378/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 ho
>>> On 16.01.17 at 18:26, wrote:
> 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
flight 104197 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104197/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-install fail REGR. vs. 104181
Regressions which
>>> On 16.01.17 at 19:46, wrote:
> 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
>>> On 16.01.17 at 18:44, 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 -0700, Jan Beuli
>>> On 17.01.17 at 05:21, wrote:
> Change in V6:
> * Change hvm_domain.pi_ops to be a pointer
> (per Boris's suggestion).
I must have overlooked that suggestion during review, and I'm afraid
it's not a good idea: See Weng Fu's series at
https://lists.xenproject.org/archives/html/xen-devel/2
>>> On 17.01.17 at 03:35, wrote:
> 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
Acked-
Hi Stefano,
On 16/01/17 19:59, Stefano Stabellini wrote:
On Mon, 16 Jan 2017, Julien Grall wrote:
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 as
Hi Jan,
On 17/01/17 09:09, Jan Beulich wrote:
On 16.01.17 at 19:46, wrote:
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 map
On Tue, Jan 17, 2017 at 12:11 AM, Jan Beulich wrote:
> >>> On 16.01.17 at 16:15, wrote:
> > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
> >
> >> For building a debug hypervisor, all you need to do is set
> >> CONFIG_DEBUG=y in xen/.config. I don't think there are any
> >> knobs to avoid
On 16/01/17 17:02, Jan Beulich wrote:
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 ma
On 16/01/17 16:16, Jan Beulich wrote:
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
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 policy object when the feature
bits may have
flight 104203 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104203/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 104195
Tests which
On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 18:44, 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:
flight 68380 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68380/
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 R
On Mon, Jan 16, 2017 at 3:16 PM, Daniel Kiper wrote:
> 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:
>> >>> I would prefer
flight 104200 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-install fail REGR. vs. 104178
test-armhf-armhf-
On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
wrote:
> On 16/01/17 16:16, Jan Beulich wrote:
> 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
>>> On 17.01.17 at 12:43, wrote:
> On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
>> >>> On 16.01.17 at 18:44, 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 Beuli
>>> On 17.01.17 at 12:22, wrote:
> On 16/01/17 16:16, Jan Beulich wrote:
> 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 ea
On Tue, Jan 17, 2017 at 12:05:21PM +, George Dunlap wrote:
> On Mon, Jan 16, 2017 at 3:16 PM, Daniel Kiper wrote:
[...]
> >> Yes there are some code changes which is the point of me sending this.
> >> But the work for you is the same as having to rebase your series over
> >> the past few yea
flight 104204 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104204/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 315d9d08fd77db1024ccc5307823da8aaed85e2f
baseline version:
ovmf 2b631390f9f5f6971c3c8
>>> On 17.01.17 at 12:27, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -80,6 +80,103 @@ static void sanitise_featureset(uint32_t *fs)
>(fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
> }
>
> +static void recalculate_xstate(struct cpuid_pol
>>> On 17.01.17 at 11:49, wrote:
> On Tue, Jan 17, 2017 at 12:11 AM, Jan Beulich wrote:
>
>> >>> On 16.01.17 at 16:15, wrote:
>> > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote:
>> >
>> >> For building a debug hypervisor, all you need to do is set
>> >> CONFIG_DEBUG=y in xen/.config. I do
>>> On 16.01.17 at 15:15, wrote:
> Doug v2 - new in this version to help show what's changed
Thanks for providing this.
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -519,6 +519,7 @@ trampoline_setup:
> 1:
> /* Switch to low-memory stack. */
> mov
Hi,
Sorry for the late answer, I am just back from holidays and still
catching-up with my e-mails.
On 03/01/17 20:08, Stefano Stabellini wrote:
On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
On 28 December 2016 at 23:19, Julien Grall wrote:
On 21/12/16 22:12, Stefano Stabellini wrote:
On W
flight 104206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104206/
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
Hi,
On 06/01/17 21:54, Stefano Stabellini wrote:
On Fri, 6 Jan 2017, Bhupinder Thakur wrote:
Hi,
I am trying to allocate a new SPI VIRQ for sending pl011 interrupt to
the guest OS. Currently Xen does not allow to allocate a SPI VIRQ for
a guest domain. I tried allocating a new SPI VIRQ by call
On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
> >>> On 17.01.17 at 12:43, wrote:
> > On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
> >> >>> On 16.01.17 at 18:44, wrote:
> >> > On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> >> >> >>> On 16.01.17 at 17:
This run is configured for baseline tests only.
flight 68381 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68381/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
>>> On 17.01.17 at 15:13, wrote:
> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
>> >>> On 17.01.17 at 12:43, wrote:
>> > If the PVH domain has access to an APIC and wants to use it it must parse
>> > the
>> > info from the MADT, or else it cannot get the APIC address or the APIC
On Tue, Jan 17, 2017 at 8:54 PM, Jan Beulich wrote:
> >>> On 17.01.17 at 11:49, wrote:
> > I was trying to figure out if I followed your instruction properly.
> > My first attempt only resulted in a binary with similar size with my
> > previous one.
> > Probably something went wrong.
> > I put m
On 17/01/17 12:29, George Dunlap wrote:
> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
> wrote:
>> On 16/01/17 16:16, Jan Beulich wrote:
>> 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
On 17/01/17 12:42, Jan Beulich wrote:
>
>>> And I'm not sure we really need to bother considering hypothetical
>>> 128-bit architectures at this point in time.
>> Because considering this case will avoid us painting ourselves into a
>> corner.
> Why would we consider this case h
On 17/01/17 04:55, Juergen Gross wrote:
> 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
On 01/17/2017 09:44 AM, Jan Beulich wrote:
On 17.01.17 at 15:13, wrote:
>> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
>> On 17.01.17 at 12:43, wrote:
If the PVH domain has access to an APIC and wants to use it it must parse
the
info from the MADT, or els
On 17/01/17 12:52, Jan Beulich wrote:
On 17.01.17 at 12:27, wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -80,6 +80,103 @@ static void sanitise_featureset(uint32_t *fs)
>>(fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
>> }
>>
>> +s
>>> On 17.01.17 at 16:15, wrote:
> On 17/01/17 12:52, Jan Beulich wrote:
> On 17.01.17 at 12:27, wrote:
>>> @@ -154,6 +152,13 @@ struct cpuid_policy
>>> };
>>> uint32_t /* b */:32, xss_low, xss_high;
>>> };
>>> +
>>> +/* Per-component common state.
On Fri, Jan 13, Julien Grall wrote:
> Regarding the format. Does ODT will allow git to do proper diff?
There is flat ODT, "Safe as ..." and pick the better format from the pulldown
menu.
Olaf
signature.asc
Description: PGP signature
___
Xen-devel ma
>>> On 17.01.17 at 16:13, wrote:
> On 17/01/17 12:42, Jan Beulich wrote:
>>
And I'm not sure we really need to bother considering hypothetical
128-bit architectures at this point in time.
>>> Because considering this case will avoid us painting ourselves into a
>>> corner
>>> On 17.01.17 at 16:27, wrote:
> On 01/17/2017 09:44 AM, Jan Beulich wrote:
> On 17.01.17 at 15:13, wrote:
>>> There's only one kind of PVHv2 guest that doesn't require ACPI, and that
>>> guest
>>> type also doesn't have emulated local APICs. We agreed that this model was
>>> interesting f
On 17/01/17 15:28, Jan Beulich wrote:
On 17.01.17 at 16:15, wrote:
>> On 17/01/17 12:52, Jan Beulich wrote:
>> On 17.01.17 at 12:27, wrote:
@@ -154,6 +152,13 @@ struct cpuid_policy
};
uint32_t /* b */:32, xss_low, xss_high;
};
+
>>> On 17.01.17 at 16:06, wrote:
> On 17/01/17 12:29, George Dunlap wrote:
>> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
>> wrote:
>>> On 16/01/17 16:16, Jan Beulich wrote:
>>> On 16.01.17 at 17:05, wrote:
> On 13/01/17 12:47, Jan Beulich wrote:
>> The kernel already has to
On 01/17/2017 10:33 AM, Jan Beulich wrote:
On 17.01.17 at 16:27, wrote:
>> On 01/17/2017 09:44 AM, Jan Beulich wrote:
>> On 17.01.17 at 15:13, wrote:
There's only one kind of PVHv2 guest that doesn't require ACPI, and that
guest
type also doesn't have emulated local APICs
This file contains data and code only used at initialization. Mark the
file as such in the build system and correct kind_guess.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/bootfdt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/ar
iomem_deny_access is working on MFN and not GFN. Make it clear by
renaming the local variables.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 6 +++---
xen/arch/arm/gic-v2.c | 18 +-
xen/arch/arm/gic-v3.c | 18 +-
3 files changed, 21 i
>>> On 17.01.17 at 16:08, wrote:
> I was lucky to capture the full log before it fills up my 100MB ring buffer
> (in less than 2 seconds).
> Please find the log in the attachment.
Sadly nothing helpful in there; I'm a little puzzled though that the
first thing we see is
(XEN) [VT-D]iommu.c:909:
Hello,
Below is a draft of a design document for PVHv2 CPU hotplug. It should cover
both vCPU and pCPU hotplug. It's mainly centered around the hardware domain,
since for unprivileged PVH guests the vCPU hotplug mechanism is already
described in Boris series [0], and it's shared with HVM.
The aim
In fact, there is one scratch mask per each CPU. When
you use the one of a CPU, it must be true that:
- the CPU belongs to your cpupool and scheduler,
- you own the runqueue lock (the one you take via
{v,p}cpu_schedule_lock()) for that CPU.
This was not the case within the following functions
Hello,
This series fixes a few issues issues, related to Credit2 and to scheduling and
cpupools interactions in a more general fashion.
The first 3 patches cures (symptoms of) bugs in Credit2, and should be
backported to 4.8 (it should not be too hard to do so, and I can help with
that, if necess
In fact, during shutdown/suspend, we temporarily move all
the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2
domains, we call csched2_vcpu_migrate(), expects to find the
target pCPU in the domain's pool
Therefore, if Credit2 is the default scheduler and we have
removed pCPU 0 from cpupool
In fact, when domains are being unpaused:
- it's not necessary to put the vcpu to sleep, as
they are all already paused;
- it is not necessary to call vcpu_migrate(), as
the vcpus are still paused, and therefore won't
wakeup anyway.
Basically, the only important thing is to call
pick_cp
The tools that use kexec are asynchronous in nature and do not keep
state changes. As such provide an hypercall to find out whether an
image has been loaded for either type.
Note: No need to modify XSM as it has one size fits all check and
does not check for subcommands.
Note: No need to check KE
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Dur
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
--
Reviewed-by: Jan Beulich
Cc: Ian Jackson
Acked-by: Wei Liu
Cc: Andrew Cooper
Cc: Daniel De Graaf
v4:
- #define u
Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.
[1] https://lists.xenproject.org
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
---
Reviewed-by: Jan
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. In practice
the value passed was always tr
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by:
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
N
In fact, relying on the mask of what pCPUs belong to
which Credit2 runqueue is not enough. If we only do that,
when Credit2 is the boot scheduler, we may ASSERT() or
panic when moving a pCPU from Pool-0 to another cpupool.
This is because pCPUs outside of any pool are considered
part of cpupool0.
It is ok to use just cpumask_scratch in csched_runq_steal().
In fact, the cpu parameter comes from the cpu local variable
in csched_load_balance(), which in turn comes from cpu in
csched_schedule(), which is smp_processor_id().
While there, also:
- move the comment about cpumask_scratch in the he
On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
> On 01/17/2017 10:33 AM, Jan Beulich wrote:
> On 17.01.17 at 16:27, wrote:
> >> On 01/17/2017 09:44 AM, Jan Beulich wrote:
> >> On 17.01.17 at 15:13, wrote:
> There's only one kind of PVHv2 guest that doesn't require
Hi,
I am trying to develop PV audio drivers and facing one issue to
achieve zero copy of the buffers between Front End (DOM1) and
Back End (DOM0) drivers.
When the buffer is allocated using __get_free_pages() on the DOM0
OS, I am able to grant the access using gnttab_grant_foreign_access()
to
On Mon, Jan 16, 2017 at 01:04:09PM +, 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
On Mon, Jan 16, 2017 at 05:09:24PM -0800, Stefano Stabellini wrote:
> 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(+)
> >
> > dif
On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 16, 2017 at 01:04:09PM +, 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 t
On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote:
> On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote:
> >> The chageset/version/compile information is currently exported as a set of
> >> function calls into a separate tra
On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
> On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
>> On 01/17/2017 10:33 AM, Jan Beulich wrote:
>> On 17.01.17 at 16:27, wrote:
On 01/17/2017 09:44 AM, Jan Beulich wrote:
On 17.01.17 at 15:13, wrote:
>> There's
flight 104202 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104202/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104181
test-armhf-armhf-libvirt-xs
On Tue, Jan 17, 2017 at 01:42:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote:
> > On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper wrote:
> > >> The chageset/version/compile inform
On Tue, 17 Jan 2017, Julien Grall wrote:
> Hi,
>
> Sorry for the late answer, I am just back from holidays and still catching-up
> with my e-mails.
>
> On 03/01/17 20:08, Stefano Stabellini wrote:
> > On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> > > On 28 December 2016 at 23:19, Julien Grall w
This run is configured for baseline tests only.
flight 68383 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68383/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
On Tue, 17 Jan 2017, Olaf Hering wrote:
> On Fri, Jan 13, Julien Grall wrote:
>
> > Regarding the format. Does ODT will allow git to do proper diff?
>
> There is flat ODT, "Safe as ..." and pick the better format from the pulldown
> menu.
Sounds like a good idea. Can you submit a patch?
__
flight 104208 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104208/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail like 104176
test-armhf-armhf-libvirt-x
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
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
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
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
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
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
On 17/01/17 19:00, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2017 at 01:42:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue, Jan 17, 2017 at 06:16:36PM +, Andrew Cooper wrote:
>>> On 17/01/17 18:05, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 16, 2017 at 01:04:09PM +, Andrew Cooper
On 17/01/17 17:29, Eric DeVolder wrote:
> The tools that use kexec are asynchronous in nature and do not keep
> state changes. As such provide an hypercall to find out whether an
> image has been loaded for either type.
>
> Note: No need to modify XSM as it has one size fits all check and
> does no
> > Is this patch of yours that neccessary? Could at least some of the
> > functions still exist?
>
> Well. This patch is manually doing what LTO would do automatically when
> it has a cross-translation-unit view of things, and come to the
> conclusion that in all cases, inlining cross-unit will
vif->lock is used to protect statistics gathering agents from using the
queue structure during cleaning.
Signed-off-by: Igor Druzhinin
---
drivers/net/xen-netback/interface.c | 6 --
drivers/net/xen-netback/xenbus.c| 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/dr
Just split the initial patch in two as proposed by Wei.
Since the approach for locking netdev statistics is inconsistent (tends not
to have any locking at all) accross the kernel we'd better to rely on our
internal lock for this purpose.
Igor Druzhinin (2):
xen-netback: fix memory leaks on XenB
Eliminate memory leaks introduced several years ago by cleaning the
queue resources which are allocated on XenBus connection event. Namely, queue
structure array and pages used for IO rings.
Signed-off-by: Igor Druzhinin
---
drivers/net/xen-netback/xenbus.c | 11 +++
1 file changed, 11 i
flight 104213 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104213/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104000
test-amd64-amd64-xl-qemuu-win7-a
On Tue, Jan 17, 2017 at 11:29:16AM -0600, Eric DeVolder wrote:
> The tools that use kexec are asynchronous in nature and do not keep
> state changes. As such provide an hypercall to find out whether an
> image has been loaded for either type.
>
> Note: No need to modify XSM as it has one size fits
Hi all,
I would like to discuss with ARM64 and ACPI Linux maintainers the best
way to complete ACPI support in Linux for Dom0 on ARM64.
As a reminder, Xen can only parse static ACPI tables. It doesn't have a
bytecode interpreter. Xen maps all ACPI tables to Dom0, which parses
them as it does on
>>> On 14.12.16 at 14:15, wrote:
> On 14/12/16 12:58, Jan Beulich wrote:
> On 14.12.16 at 12:12, wrote:
>>> When EFI booting the Dell OptiPlex 9020, it sometimes GP faults in the
>>> EFI runtime instead of rebooting.
>> Has it been understood what the #GP is due to? I.e. is it namely
>> not b
On 01/16/2017 09:15 AM, Juergen Gross wrote:
> 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,
On Tue, 2017-01-17 at 06:02 +, #PATHANGI JANARDHANAN JATINSHRAVAN#
wrote:
> But I am not able to parse the hexadecimal string as shown above.
>
> Can anyone point me in the right direction regarding this?
>
I'm afraid I can't.
At the same time, I'm quite sure that by sending the same exact
On Tue, 17 Jan 2017, Julien Grall wrote:
> This file contains data and code only used at initialization. Mark the
> file as such in the build system and correct kind_guess.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/Makefile | 2 +-
> xen/arch/arm/bootfdt
On Tue, 17 Jan 2017, Julien Grall wrote:
> iomem_deny_access is working on MFN and not GFN. Make it clear by
> renaming the local variables.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/domain_build.c | 6 +++---
> xen/arch/arm/gic-v2.c | 18 +
On Tue, 17 Jan 2017, Ughreja, Rakesh A wrote:
> Hi,
>
> I am trying to develop PV audio drivers and facing one issue to
> achieve zero copy of the buffers between Front End (DOM1) and
> Back End (DOM0) drivers.
You might want to take a look at the existing PV sound proposal:
http://marc.info/?
Since we are doing cpumask manipulation already, clear a bit
in the mask at once. Doing that will save us an if, later in
the code.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |5 ++---
1 file changed, 2 insertions(+), 3
1 - 100 of 134 matches
Mail list logo
