On June 16, 2016 5:05 PM, Jan Beulich wrote:
> >>> On 16.06.16 at 10:42, wrote:
> > On June 02, 2016 7:07 PM, Jan Beulich wrote:
> >> >>> On 01.06.16 at 11:05, wrote:
> >> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> >> > +
>>> On 16.06.16 at 18:49, wrote:
> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>> The IO-APIC address has variable bits determined by the PCI-to-ISA
>> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
>> that there's still implicit rather than explicit agreement on the
>> IO-A
flight 95818 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94729
Tests which are failing
Up to now the vm_assist hypercall hasn't been supported on ARM, as
there are only x86 specific features to switch. Add support of
vm_assist on ARM for future use.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V2: readded the #ifdef's as requested by Jan Beulich
---
xen/arch/arm/tra
In order to support reading another vcpu's mapped vcpu_runstate_info
an indicator for an occurring update of the runstate information is
needed.
Add the possibility to activate setting this indicator in the highest
bit of state_entry_time via a vm_assist hypercall. When activated the
update indica
There has been a report about incorrect vruntime accounting in Linux
guests under Xen. A Linux kernel with CONFIG_PARAVIRT_TIME_ACCOUNTING
set is capable to do correct vruntime accounting, but this would
require the kernel to be able to read the runstate data of other cpus.
A guest mapping vcpu_ru
From: Quan Xu
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return
From: Quan Xu
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/iommu.c | 50 ++--
xen/drivers/passthrough/vtd/iommu.h | 11 +---
xen/drivers/passthrough/vtd
From: Quan Xu
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
From: Quan Xu
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 3 ++-
xen/drivers/passthrough/vtd/iommu.c | 8
xen/drivers/passthrough/vtd/quirks.c | 27 +-
On 2016/6/6 19:40, Stefano Stabellini wrote:
> ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
> config file enables them, with default off.
While the configuration "acpi" already exists for HVM guest
configuration, do we plan to reuse it or use a new name, e.g. arm_acpi?
QEMU_TAG update to 698d6d6f8d095edadb0c23612b552a89dd3eee4c of traditional qemu
in Config.mk, this commit is a branch stable-4.7 commit for qemu traditional.
The master commit is 6e20809727261599e8527c456eb078c0e89139a1.
It bring up a build error.
commit 03c716e32912e288929a6e0d9c8729d208462d66
On 2016/6/16 19:20, Wei Liu wrote:
> I've read this sub-thread and the other thread in which Boris replied, I
> think due to the fact that libxl has more information at hand and libxc
> is intended to be simple, I think having the building code in libxl
> makes sense.
>
> Shannon, Boris and Juli
flight 95814 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95814/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
flight 95809 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 3 host-install(3) broken in 95762 REGR. vs. 94728
test-amd64-amd64-qemuu
flight 95801 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95801/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 95353
build-amd64-rumpuserxen
> I suggest pasting in Olaf's exact error message here.
>
> To avoid extra round trip, I propose updating the commit message as
> followed:
>
> Initialise j to 0 to make some versions of gcc (e.g., gcc4.5/4.3)
> happy to
> avoid compilation error by commit
> beba3693f7243e68bbe31fe3794da
On 16/06/2016 20:24, Corneliu ZUZU wrote:
On 6/16/2016 5:26 PM, Julien Grall wrote:
Hi Julien. Yes, I agree that it's complex, I would have preferred to
split it up too and I actually tried, but the changes are tightly
coupled and they don't seem to be 'split-able'.
After I reviewed this patc
flight 95804 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 86412
test-amd64-amd64-qemuu
On 06/16/16 23:10, Corneliu ZUZU wrote:
> On 6/16/2016 5:51 PM, Jan Beulich wrote:
> On 16.06.16 at 16:08, wrote:
>>> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>> +vm_event_vcpu_enter(v);
>> Why here?
> Why indeed. It made sense because monitor_w
>>> +unsigned long flags;
>>> +u64 tsc;
>>> +
>>> +local_irq_save(flags);
>>> +ap_bringup_ref.master_stime = read_platform_stime();
>>> +tsc = rdtsc();
>>> +local_irq_restore(flags);
>>> +
>>> +ap_bringup_ref.local_stime = get_s_time_fixed(tsc);
>>> +}
>>> +
>>> void in
On 6/16/2016 6:00 PM, Jan Beulich wrote:
On 16.06.16 at 16:09, wrote:
@@ -2199,7 +2153,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
if ( hvm_event_crX(CR0, value, old_value) )
{
-/* The actual write will occur in hvm_do_resume(), if permitted.
On 6/16/2016 5:51 PM, Jan Beulich wrote:
On 16.06.16 at 16:08, wrote:
@@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
}
}
+vm_event_vcpu_enter(v);
Why here?
Why indeed. It made sense because monitor_write_data handling was
originally there and then the plan was t
On 6/16/2016 5:26 PM, Julien Grall wrote:
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
Add ARM support for control-register write monitoring through the
vm-events
subsystem.
Chosen ARM system control-registers that can be monitored are:
- VM_EVENT_ARM_SCTLR: AArch32 SCTLR
On 6/16/2016 5:24 PM, Jan Beulich wrote:
On 16.06.16 at 16:06, wrote:
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index d950a7c
flight 95783 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 3 host-install(3) broken REGR. vs. 94856
test-amd64-i386-xl
On Thu, 16 Jun 2016, Roger Pau Monné wrote:
> I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a
> try when you have a moment?
Yes, of course. A quick test shows no change - Windows get stuck
at the UEFI shell with some block devices listed (I use "hda" for
Windows), SeaBI
On Thu, Jun 16, 2016 at 8:12 AM, Corneliu ZUZU wrote:
> Prepare for ARM implementation of control-register write vm-events by moving
> X86-specific hvm_event_cr to the common-side.
>
> Signed-off-by: Corneliu ZUZU
> ---
> xen/arch/x86/hvm/event.c| 30 --
> xen
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8c50685..af61ac3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "decode.h"
#include
On 06/16/2016 05:40 AM, Jan Beulich wrote:
> The IO-APIC address has variable bits determined by the PCI-to-ISA
> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
> that there's still implicit rather than explicit agreement on the
> IO-APIC base address between qemu and the hy
flight 95800 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95800/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164
test-amd64-amd64-qemuu
On 06/16/2016 12:04 PM, Jan Beulich wrote:
On 16.06.16 at 17:37, wrote:
>> On 06/16/2016 11:25 AM, Jan Beulich wrote:
>> On 16.06.16 at 17:09, wrote:
On 06/16/2016 05:40 AM, Jan Beulich wrote:
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
+++ b/tools/firmware/hvmloade
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 1fec412..1e5445f 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -20,7 +20,6 @@
> */
>
> #include
> -#include
>
> int arch_monitor_domctl_event(struct domain *d,
>s
On Thu, Jun 16, 2016 at 8:08 AM, Corneliu ZUZU wrote:
> In an effort to improve on the vm-event interface, we introduce a new function
> called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
> function - i.e. it should be called by implementing architectures just before
> re
On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU wrote:
> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
> vm_event_regist
>>> On 16.06.16 at 17:37, wrote:
> On 06/16/2016 11:25 AM, Jan Beulich wrote:
> On 16.06.16 at 17:09, wrote:
>>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>>>
>>> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
>>> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c
>>> @@ -150,6 +150,14 @@ int main
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index 014d9ba..05c3027 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -23,21 +23,18 @@
> #include
> #include
>
> -static inline
> -int vm_event_init_domain(struct domain *
On 06/16/2016 11:25 AM, Jan Beulich wrote:
On 16.06.16 at 17:09, wrote:
>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>>
>> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
>> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c
>> @@ -150,6 +150,14 @@ int main(int argc, char **argv)
>> indent();
On Mon, Jun 13, 2016 at 07:26:30PM +, Marcin Cieslak wrote:
> On Mon, 13 Jun 2016, Roger Pau Monné wrote:
>
> > On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote:
> > > "?" does not work - it mostly causes a panic, the console is slow, but I
> > > managed
> > > to switch it to /d
>>> On 16.06.16 at 17:09, wrote:
> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>
> --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
> +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c
> @@ -150,6 +150,14 @@ int main(int argc, char **argv)
> indent(); printf("MSU, 8\n");
> pop_block();
>
> +
>>> On 16.06.16 at 16:12, wrote:
> Prepare for ARM implementation of control-register write vm-events by moving
> X86-specific hvm_event_cr to the common-side.
>
> Signed-off-by: Corneliu ZUZU
> ---
> xen/arch/x86/hvm/event.c| 30 --
> xen/arch/x86/hvm/hvm.c
On 06/16/2016 05:40 AM, Jan Beulich wrote:
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c
@@ -150,6 +150,14 @@ int main(int argc, char **argv)
indent(); printf("MSU, 8\n");
pop_block();
+/* Processor object helpers. */
+push_block("M
>>> On 16.06.16 at 16:09, wrote:
> @@ -2199,7 +2153,9 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
>
> if ( hvm_event_crX(CR0, value, old_value) )
> {
> -/* The actual write will occur in hvm_do_resume(), if permitted.
> */
> +/* The actual
>>> On 16.06.16 at 16:08, wrote:
> @@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
> }
> }
>
> +vm_event_vcpu_enter(v);
Why here?
> @@ -3874,6 +3875,9 @@ void vmx_vmenter_helper(const struct cpu_user_regs
> *regs)
> }
>
> out:
> +if ( guest_mode(regs) )
>
On 16/06/16 14:36, Jan Beulich wrote:
On 16.06.16 at 14:11, wrote:
>> On 16/06/16 13:15, Jan Beulich wrote:
>> On 15.06.16 at 13:34, wrote:
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+off = offsetof(struct vcpu_runstate_info, state_entry_time) +
On 06/16/2016 07:15 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> From: Kővágó, Zoltán
>>
>> Except qapi-schema.json, this patch was generated by:
>>
>> find . -name .git -prune -o -type f \! -name '*~' -print0 | \
>> xargs -0 sed -i \
>> -e 's/NetClientOptionsKind/NetClientDriver
Hello Corneliu,
On 16/06/16 15:13, Corneliu ZUZU wrote:
Add ARM support for control-register write monitoring through the vm-events
subsystem.
Chosen ARM system control-registers that can be monitored are:
- VM_EVENT_ARM_SCTLR: AArch32 SCTLR, AArch64 SCTLR_EL1
- VM_EVENT_ARM_TTBR
>>> On 16.06.16 at 16:06, wrote:
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index d950a7c..b30857a 100644
> ---
After trapping a control-register write vm-event and -until- deciding if that
write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual write,
there cannot and should not be another trapped control-register write event.
That is: currently -only one- of the fields of monitor_write_da
For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the
vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag set
should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
vm_event_register_write_resume().
Signed-off-by: Corneliu ZUZU
---
xen/arch
Add ARM support for control-register write monitoring through the vm-events
subsystem.
Chosen ARM system control-registers that can be monitored are:
- VM_EVENT_ARM_SCTLR: AArch32 SCTLR, AArch64 SCTLR_EL1
- VM_EVENT_ARM_TTBR{0,1}: AArch32 TTBR{0,1}, AArch64 TTBR{0,1}_EL1
- VM_EVE
Prepare for ARM implementation of control-register write vm-events by moving
X86-specific hvm_event_cr to the common-side.
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/event.c| 30 --
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/monitor.c
After introducing vm_event_vcpu_enter, it makes sense to move the following
code there:
- handling of monitor_write_data from hvm_do_resume
- enabling/disabling CPU_BASED_CR3_LOAD_EXITING from vmx_update_guest_cr(v, 0)
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/hvm.c | 62 +--
In an effort to improve on the vm-event interface, we introduce a new function
called vm_event_vcpu_enter. Its significance is that of a "final touch" vCPU
function - i.e. it should be called by implementing architectures just before
re-entering vCPUs.
On X86 for example, it is called on the schedu
Minor fixes:
- fix 80-columns formatting in some places
- remove some empty lines
- remove some unused includes
- add 2 comments
Signed-off-by: Corneliu ZUZU
---
xen/arch/arm/domain.c | 1 -
xen/arch/arm/traps.c| 1 -
xen/arch/x86/hvm/event.c| 1 +
Add ARM support for control-register write vm-events.
Patch-series summary:
1. [minor] small (formatting & other) fixes
2. [minor] fix an issue w/ VM_EVENT_FLAG_DENY
3+4. [major] introduce a new vm-event function (vm_event_vcpu_enter) that
gets executed just before a vCPU is (re)e
On 16/06/16 15:07, Stefano Stabellini wrote:
> On Thu, 16 Jun 2016, Juergen Gross wrote:
>> On 16/06/16 12:54, Jan Beulich wrote:
>> On 16.06.16 at 12:02, wrote:
In case the word size of the domU and qemu running the qdisk backend
differ BLKIF_OP_DISCARD will not work reliably, as th
On 06/16/2016 07:20 AM, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
>> Hello Shannon,
>>
>> On 07/06/16 02:07, Shannon Zhao wrote:
>>> On 2016/6/6 23:48, Julien Grall wrote:
On 06/06/16 13:26, Wei Liu wrote:
> On Tue, May 31, 2016 at 01:02:52PM +0800, Sha
Eric Blake writes:
> From: Kővágó, Zoltán
>
> Except qapi-schema.json, this patch was generated by:
>
> find . -name .git -prune -o -type f \! -name '*~' -print0 | \
> xargs -0 sed -i \
> -e 's/NetClientOptionsKind/NetClientDriver/g' \
> -e 's/NET_CLIENT_OPTIONS_KIND_/NET_CLIENT_DRIVER
On 06/16/2016 04:54 AM, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 11:15:22AM -0400, Boris Ostrovsky wrote:
> [...]
>>> +static int init_acpi_config(struct xc_dom_image *dom,
>>> +struct acpi_config *config)
>>> +{
>>> +xc_interface *xch = dom->xch;
>>> +uint32_t d
On Thu, 16 Jun 2016, Juergen Gross wrote:
> On 16/06/16 12:54, Jan Beulich wrote:
> On 16.06.16 at 12:02, wrote:
> >> In case the word size of the domU and qemu running the qdisk backend
> >> differ BLKIF_OP_DISCARD will not work reliably, as the request
> >> structure in the ring have differ
On Thu, Jun 16, 2016 at 01:36:32PM +0100, David Vrabel wrote:
> On 16/06/16 13:16, Wei Liu wrote:
> > On Mon, Jun 13, 2016 at 11:43:55AM +0200, Paulina Szubarczyk wrote:
> >> Implentation of interface for grant copy operation in libs and
> >> libxc.
> >>
> >> In a linux part an ioctl(gntdev, IOCTL_
flight 95775 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
>>> On 16.06.16 at 13:18, wrote:
> On 6/16/2016 6:02 PM, Jan Beulich wrote:
>>> +struct xen_hvm_map_mem_type_to_ioreq_server {
>>> +domid_t domid; /* IN - domain to be serviced */
>>> +ioservid_t id; /* IN - ioreq server id */
>>> +uint16_t type; /* IN -
On 16/06/16 13:16, Wei Liu wrote:
> On Mon, Jun 13, 2016 at 11:43:55AM +0200, Paulina Szubarczyk wrote:
>> Implentation of interface for grant copy operation in libs and
>> libxc.
>>
>> In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
>> system call is invoked. In mini-os the operation
>>> On 16.06.16 at 14:11, wrote:
> On 16/06/16 13:15, Jan Beulich wrote:
> On 15.06.16 at 13:34, wrote:
>>> +if ( VM_ASSIST(v->domain, runstate_update_flag) )
>>> +{
>>> +off = offsetof(struct vcpu_runstate_info, state_entry_time) +
>>> + sizeof(v->runstate.state_
>>> On 16.06.16 at 13:52, wrote:
> On Thu, Jun 16, 2016 at 05:37:03AM -0600, Jan Beulich wrote:
>> >>> On 15.06.16 at 16:31, wrote:
>> > +printk("**\n");
>> > +printk("*** WARNING: HVM FORCED EMULATION PREFIX IS
>> > PERMITTED\n");
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 16 June 2016 13:19
> To: Paul Durrant; qemu-de...@nongnu.org; xen-de...@lists.xensource.com
> Cc: Anthony Perard; sstabell...@kernel.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH] xen: fix qdisk BLKIF_OP_
On Thu, Jun 16, 2016 at 01:12:34PM +0100, Andrew Cooper wrote:
> On 16/06/16 12:52, Wei Liu wrote:
> >
> >>> +printk("**\n");
> >>> +printk("*** WARNING: HVM FORCED EMULATION PREFIX IS
> >>> PERMITTED\n");
>
> I would say "available"
On 16/06/16 13:24, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Juergen Gross
>> Sent: 16 June 2016 11:02
>> To: qemu-de...@nongnu.org; xen-de...@lists.xensource.com
>> Cc: Anthony Perard; Juergen Gross; sstabell...@ke
On Mon, Jun 13, 2016 at 11:43:55AM +0200, Paulina Szubarczyk wrote:
> Implentation of interface for grant copy operation in libs and
> libxc.
>
> In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
> system call is invoked. In mini-os the operation is yet not
> implemented. For other OSs
On 16/06/16 12:52, Wei Liu wrote:
>
>>> +printk("**\n");
>>> +printk("*** WARNING: HVM FORCED EMULATION PREFIX IS
>>> PERMITTED\n");
I would say "available" rather than permitted in this case.
>>> +printk("*** This optio
On 16/06/16 13:15, Jan Beulich wrote:
On 15.06.16 at 13:34, wrote:
>> In order to support reading another vcpu's mapped vcpu_runstate_info
>> an indicator for an occurring update of the runstate information is
>> needed.
>>
>> Add the possibility to activate setting this indicator in the high
flight 95788 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 80927
test-am
On Thu, Jun 16, 2016 at 05:37:03AM -0600, Jan Beulich wrote:
> >>> On 15.06.16 at 16:31, wrote:
> > @@ -182,6 +181,32 @@ static int __init hvm_enable(void)
> > if ( !opt_altp2m_enabled )
> > hvm_funcs.altp2m_supported = 0;
> >
> > +if ( opt_hvm_fep )
> > +{
> > +uns
>>> On 15.06.16 at 16:31, wrote:
> @@ -182,6 +181,32 @@ static int __init hvm_enable(void)
> if ( !opt_altp2m_enabled )
> hvm_funcs.altp2m_supported = 0;
>
> +if ( opt_hvm_fep )
> +{
> +unsigned i, j;
unsigned int
> +printk("***
On 16/06/16 12:26, Jan Beulich wrote:
> @@ -570,6 +589,15 @@ void fatal_trap(const struct cpu_user_re
> printk("Faulting linear address: %p\n", _p(cr2));
> show_page_walk(cr2);
> }
> +if ( show_remote )
> +{
> +cpumask_andnot(&show_stat
Quite frequently the watchdog would hit an innocent CPU, e.g. one
trying to acquire a spin lock a remote CPU holds for extended periods
of time, or a random CPU in TSC calbration rendezvous. In such cases
the register and stack dump for that CPU doesn't really help in the
analysis of the problem.
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 16 June 2016 11:02
> To: qemu-de...@nongnu.org; xen-de...@lists.xensource.com
> Cc: Anthony Perard; Juergen Gross; sstabell...@kernel.org;
> kra...@redhat.com
> Subject: [Xen
On 6/16/2016 6:02 PM, Jan Beulich wrote:
@@ -94,8 +96,16 @@ static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t
mfn,
default:
return flags | _PAGE_NX_BIT;
case p2m_grant_map_ro:
-case p2m_ioreq_server:
return flags | P2M_BASE_FLAGS | _PAGE_NX_
On Tue, Jun 07, 2016 at 12:00:26PM +0100, Julien Grall wrote:
> Hello Shannon,
>
> On 07/06/16 02:07, Shannon Zhao wrote:
> >On 2016/6/6 23:48, Julien Grall wrote:
> >>On 06/06/16 13:26, Wei Liu wrote:
> >>>On Tue, May 31, 2016 at 01:02:52PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
> >
>>> On 16.06.16 at 13:04, wrote:
> On 16/06/16 12:54, Jan Beulich wrote:
> On 16.06.16 at 12:02, wrote:
>>> In case the word size of the domU and qemu running the qdisk backend
>>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>>> structure in the ring have different layouts
>>> On 15.06.16 at 13:34, wrote:
> In order to support reading another vcpu's mapped vcpu_runstate_info
> an indicator for an occurring update of the runstate information is
> needed.
>
> Add the possibility to activate setting this indicator in the highest
> bit of state_entry_time via a vm_assi
On 16/06/16 12:04, sarah jones wrote:
Hi,
Hello,
i'm looking for a detailed tutorial on how to install Xen on a Raspberry
Pi3 or .Ordoid C2.
I am not aware of any tutorial of one of these boards.
Regards,
--
Julien Grall
___
Xen-devel mailing
On 16/06/16 11:59, Fadwa Messaoudi wrote:
Hi,
Hello,
i m looking for a detailed tutorial on how to install Xen on a the Hikey
Board.
You can give a look to Xen wiki:
http://wiki.xenproject.org/wiki/HiKey
Regards,
--
Julien Grall
___
Xen-deve
On Thu, Jun 16, 2016 at 06:53:37PM +0800, Shannon Zhao wrote:
>
>
> On 2016/6/16 18:49, Wei Liu wrote:
> > On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
> > [...]
> >> > That's its own mechanism I think and UEFI wants all the memory maps
> >> > under its control. And it's same for
Hi,
i'm looking for a detailed tutorial on how to install Xen on a Raspberry
Pi3 or .Ordoid C2.
Any information can help me a lot
Best Regards.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hello Shannon,
On 16/06/16 11:45, Shannon Zhao wrote:
On 2016/6/7 21:06, Julien Grall wrote:
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen
On 16/06/16 12:54, Jan Beulich wrote:
On 16.06.16 at 12:02, wrote:
>> In case the word size of the domU and qemu running the qdisk backend
>> differ BLKIF_OP_DISCARD will not work reliably, as the request
>> structure in the ring have different layouts for different word size.
>>
>> Correct t
Hi,
i m looking for a detailed tutorial on how to install Xen on a the Hikey
Board.
Thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 2016/6/16 18:49, Wei Liu wrote:
> On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
> [...]
>> > That's its own mechanism I think and UEFI wants all the memory maps
>> > under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>> > on x86. You can have a look at the
On 15/06/16 16:11, Fadwa Messaoudi wrote:
Hi,
Hello,
i'm working on the dragonboard trying to install Xen on it, do you have
any documentation to help me and ease my work.
I am not aware of any tutorial on how to install Xen on this board.
After looking at the hardware specification of t
>>> On 16.06.16 at 12:02, wrote:
> In case the word size of the domU and qemu running the qdisk backend
> differ BLKIF_OP_DISCARD will not work reliably, as the request
> structure in the ring have different layouts for different word size.
>
> Correct this by copying the request structure in cas
On 16/06/16 10:12, sarah jones wrote:
Hi,
Hello Sarah,
i couldn't find any tutorials on how to install Xen on a Dragon Board
Could you help me please with the steps to get this done
I am not aware of any tutorial on how to install Xen on this board.
After looking at the hardware specific
On Tue, Jun 07, 2016 at 08:32:26PM +0800, Shannon Zhao wrote:
[...]
> That's its own mechanism I think and UEFI wants all the memory maps
> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
> is used for
On 2016/6/16 18:21, Julien Grall wrote:
>
>
> On 16/06/16 07:53, Shannon Zhao wrote:
>> Hi Julien,
>
> Hi Shannon,
>
>>
>> On 2016/6/7 21:06, Julien Grall wrote:
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM
Hi all
Xen 4.7 rc6 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.7.0-rc6
For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc6/xen-4.7.0-rc6.tar.gz
And the signature is at:
http://bits.xensource.com/oss-xen/release/
On 16/06/16 07:53, Shannon Zhao wrote:
Hi Julien,
Hi Shannon,
On 2016/6/7 21:06, Julien Grall wrote:
That's its own mechanism I think and UEFI wants all the memory maps
under its control. And it's same for QEMU(x86 and ARM) and also for Xen
on x86. You can have a look at the OvmfPkg/AcpiP
On 16/06/16 10:52, Stefano Stabellini wrote:
> On Wed, 15 Jun 2016, George Dunlap wrote:
>> Add a 4.7 config file, make it the default.
>>
>> Also update the qemu and qemu_traditional recipies after Ian Cambell's
>> work to split off separate libraries.
>>
>> Signed-off-by: George Dunlap
>
> Acke
>>> On 16.06.16 at 11:32, wrote:
>> On 6/14/2016 6:45 PM, Jan Beulich wrote:
>>> On 19.05.16 at 11:05, wrote:
> @@ -914,6 +916,45 @@ int hvm_unmap_io_range_from_ioreq_server(struct
> domain
>>> *d, ioservid_t id,
>return rc;
>}
>
> +int hvm_map_mem_typ
1 - 100 of 125 matches
Mail list logo
