>>> On 10.05.16 at 05:41, wrote:
> On May 10, 2016 12:14 AM, Jan Beulich wrote:
>> >>> On 06.05.16 at 10:54, wrote:
>> > --- a/xen/drivers/passthrough/iommu.c
>> > +++ b/xen/drivers/passthrough/iommu.c
>> > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d,
>> unsigned long gfn, unsigned
Hi,
I added a new hypercall to xen successfully, but when i try to invoke it in
dom0 using privcmd, i am unable to invoke (using XC), I must cd to
/xen.x.y.z/tools/xcutils and then try to invoke hypercall by XC interface which
i created for it.
DO functions of hypercall is written in /xen/common
Thanks.
would you please tell me what do you mean by top-post?
No, A Xen running inside Vmware does not crash until i modified it. it is not
because of vmware at all (it may be caused because of my wrong development). in
fact when i can understand the performance difference Xen is working on vmwa
>>> On 09.05.16 at 18:19, wrote:
> On 06/05/16 09:12, Jan Beulich wrote:
> On 29.04.16 at 11:35, wrote:
>>> As discussed on the hackathon, avoid us having to issue security
>>> advisories for issues affecting only heavily disaggregated tool stack
>>> setups, which no-one appears to use (or el
Hello,
In the latest build of XenNet for Windows (April 1st 2016), it does not
connect automatically to the network card. I found that the devide IDs
are not right in the inf file, they are :
XENVIF\VEN_XP0001&DEV_NET&REV_0809
XENVIF\VEN_XP0002&DEV_NET&REV_0809
they should be
Author: Peter Maydell
Date: Mon May 9 13:42:25 2016 +0100
Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into
staging
vga security fixes (CVE-2016-3710, CVE-2016-3712)
# gpg: Signature made Mon 09 May 2016 13:39:30 BST using RSA key I
On 10/05/16 04:18, Dario Faggioli wrote:
> [removing Vitaly, adding Juergen]
>
> On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote:
>>
>>> On 9 May 2016, at 17:03, George Dunlap
>>> wrote:
>>> On Mon, May 9, 2016 at 4:28 PM, Lars Kurth
>>> wrote:
- George: are there any manual te
On May 10, 2016 12:14 AM, Jan Beulich wrote:
> >>> On 06.05.16 at 10:54, wrote:
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d,
> unsigned long gfn, unsigned long mfn,
> > unsign
On 5/9/16 10:28 AM, Lars Kurth wrote:
> Hi all,
>
> I added the following sections based on git logs to man pages. Authors are on
> the CC list and should review and modify (or suggest edits by replying to
> this thread). I added/updated/added TODO's to:
>
> I do have some questions, to ...
> -
>>> On 5/9/2016 at 11:28 PM, in message
<6db04875-03d4-4542-b06c-2b0412d08...@gmail.com>, Lars Kurth
wrote:
> Hi all,
>
> I added the following sections based on git logs to man pages. Authors are
> on the CC list and should review and modify (or suggest edits by replying to
> this threa
[removing Vitaly, adding Juergen]
On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote:
>
> > On 9 May 2016, at 17:03, George Dunlap
> > wrote:
> > On Mon, May 9, 2016 at 4:28 PM, Lars Kurth
> > wrote:
> > >
> > > - George: are there any manual tests for credit 2 hard affinity,
> > > for hotplu
flight 93919 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93919/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 92434
t
flight 93918 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93918/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On 2016/5/10 0:17, Julien Grall wrote:
> (CC Shannon, Stefano and Steve)
>
> Hi Lars,
>
> On 09/05/16 16:28, Lars Kurth wrote:
>> Hi all,
>>
>> I added the following sections based on git logs to man pages. Authors
>> are on the CC list and should review and modify (or suggest edits by
>> reply
On 05/03/2016 07:19 AM, Wei Liu wrote:
> On Mon, May 02, 2016 at 07:01:16PM -0600, Jim Fehlig wrote:
>> Hi all,
>>
>> This patch adds support for Xen migration stream V2 to the libvirt
>> libxl driver. In the process it fixes save/restore and migration
>> tests in OSSTest, which have been failing s
flight 93910 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93910/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93374
test-amd64-i386-xl-qemuu-win
On 05/09/2016 10:35 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of
> qemu processes"):
>> Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of
>> qemu processes"):
>>> Commit 6ef823fd added '-nodefaults' to the qemu args
flight 93903 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93903/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 921
On 04/05/2016 09:25 PM, Boris Ostrovsky wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html
When do people think they will get a chance to comme
flight 93905 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 92345
build-amd64-pvops
On 05/09/2016 02:27 PM, Andrew Cooper wrote:
> paging_invlpg() already returns a boolean indicating whether an invalidation
> is necessary or not. A return value of 0 indicates that the specified virtual
> address wasn't shadowed (or has already been flushed), cannot currently be
> cached in the T
On 05/09/2016 02:27 PM, Andrew Cooper wrote:
> hap_invlpg() is reachable from the instruction emulator, which means
> introspection and tests using hvm_fep can end up here. As such, crashing the
> domain is not an appropriate action to take.
>
> Fixing this involves rearranging the callgraph.
>
>
flight 93921 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93921/
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 12
On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote:
> gnutls_kx_set_priority, gnutls_certificate_type_set_priority and
> gnutls_protocol_set_priority were deprecated and eventually removed in
> GNUTLS 3.4. Application should use gnutls_priority_set_direct instead
> per [0].
>
> gnutls_anon_se
On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>
> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
>> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>>> On 05/09/2016 09:53 AM, Jan Beulich wrote:
>>> On 09.05.16 at 16:52, wrote:
> On 05/09/2016 04:08 AM, Jan Beulich wrote:
> On 09.05.16 a
Raising #GP under such circumstances is architecturally wrong. (Refer
to the Intel or AMD manuals describing the conditions under which the
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Acked-by: Tim Deegan
---
CC: Paul Durrant
CC: Wei Liu
v2:
* Clarified the commit message.
---
x
Some callers need the linear address (with appropriate segment base), whether
or not the limit or canonical check succeeds.
While modifying the function, change the return type to bool_t to match its
semantics.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Wei Liu
---
xen/arch
The `invlpg` instruction is documented to take a memory address, and is not
documented to suffer faults from segmentation violations. It is also
explicitly documented to be a NOP when issued on a non-canonical address.
Experimentally, and subsequently confirmed by both Intel and AMD, the
instruct
Turns out there are a lot of broken corner cases.
Changes in v2:
* Some improvements to commit messages
* Split part of the original patch 4 out, to make the new patch 5 clearer
* Add vcpu parameter to new invlpg() function, and avoid assuming 'current'
* Modify paging_invlpg() to be void, and
hap_invlpg() is reachable from the instruction emulator, which means
introspection and tests using hvm_fep can end up here. As such, crashing the
domain is not an appropriate action to take.
Fixing this involves rearranging the callgraph.
paging_invlpg() is now the central entry point. It first
paging_invlpg() already returns a boolean indicating whether an invalidation
is necessary or not. A return value of 0 indicates that the specified virtual
address wasn't shadowed (or has already been flushed), cannot currently be
cached in the TLB.
This is a performance optimisation.
Signed-off-
Hello,
> I don't think toolstack tries to load kernel to that guest physical
> address -- reading from Ivan's log it suggests toolstack loaded the
> kernel to 0x40008000.
> That (0x8000800) is the address set in PC, right? I don't think
> toolstack is in a position to sanitise that nor should it
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 09, 2016 1:14 PM
> To: Zytaruk, Kelly; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] dumping Xen stack
>
> On 09/05/16 18:11, Zytaruk, Kelly wrote:
> >
> >> -Original Message-
>
On 09/05/16 18:39, Wei Liu wrote:
On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
On 09/05/16 17:43, Ivan Pavić2 wrote:
Hello Julien,
Hello Ivan,
Julien Grall wrote:
Guest are booting with MMU disabled, so 0x80008000 will be the physical
address.
The toolstack will lo
> On 9 May 2016, at 18:37, Konrad Rzeszutek Wilk wrote:
>
> On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote:
>> Hi all,
>>
>> I added the following sections based on git logs to man pages. Authors are
>> on the CC list and should review and modify (or suggest edits by replying to
>
On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote:
>
>
> On 09/05/16 17:43, Ivan Pavić2 wrote:
> >Hello Julien,
>
> Hello Ivan,
>
> >
> >Julien Grall wrote:
> >>Guest are booting with MMU disabled, so 0x80008000 will be the physical
> >>address.
> >
> >>The toolstack will load the ke
On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote:
> Hi all,
>
> I added the following sections based on git logs to man pages. Authors are on
> the CC list and should review and modify (or suggest edits by replying to
> this thread). I added/updated/added TODO's to:
>
> I do have some
On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>> On 05/09/2016 09:53 AM, Jan Beulich wrote:
>> On 09.05.16 at 16:52, wrote:
On 05/09/2016 04:08 AM, Jan Beulich wrote:
On 09.05.16 at 00:51, wrote:
>> I'm try to compile kernel 4
On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>
> On 05/09/2016 09:53 AM, Jan Beulich wrote:
> On 09.05.16 at 16:52, wrote:
>>> On 05/09/2016 04:08 AM, Jan Beulich wrote:
>>> On 09.05.16 at 00:51, wrote:
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and
On Mon, May 9, 2016 at 11:28 AM, Lars Kurth wrote:
> Hi all,
>
> I added the following sections based on git logs to man pages. Authors are on
> the CC list and should review and modify (or suggest edits by replying to
> this thread). I added/updated/added TODO's to:
>
> I do have some questions
On 09/05/16 18:11, Zytaruk, Kelly wrote:
>
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Monday, May 09, 2016 12:40 PM
>> To: Zytaruk, Kelly; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] dumping Xen stack
>>
>> On 09/05/16 17:37, Zytaruk, Ke
On 09/05/16 17:56, Lars Kurth wrote:
On 9 May 2016, at 17:17, Julien Grall wrote:
(CC Shannon, Stefano and Steve)
Hi Lars,
On 09/05/16 16:28, Lars Kurth wrote:
Hi all,
I added the following sections based on git logs to man pages. Authors are on
the CC list and should review and modify
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, May 09, 2016 12:40 PM
> To: Zytaruk, Kelly; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] dumping Xen stack
>
> On 09/05/16 17:37, Zytaruk, Kelly wrote:
> > Does Xen have an equivalent func
Ian Jackson writes ("Re: [PATCH v6 1/6] libxl: handle error from
libxl__need_xenpv_qemu() correctly"):
> Wei Liu writes ("Re: [PATCH v6 1/6] libxl: handle error from
> libxl__need_xenpv_qemu() correctly"):
> > On Thu, Mar 31, 2016 at 07:49:01AM +0200, Juergen Gross wrote:
> > > In case libxl__nee
Ian Jackson writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of
uninitialized variable"):
> Wei Liu writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of
> uninitialized variable"):
> > Ian, this is a backport candidate.
>
> Noted, thanks.
Backported to 4.6 and 4.5.
Ian.
___
Ian Jackson writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy
stream"):
> Andrew Cooper writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy
> stream"):
> > Ian: This is also a backport candidate for 4.6
>
> Queued for backport.
Pushed to 4.6.
Ian.
___
Hello Julien,
Julien Grall wrote:
> Guest are booting with MMU disabled, so 0x80008000 will be the physical
> address.
> The toolstack will load the kernel at this physical address. However,
> the start of the guest RAM for Xen 4.7 is 0x4000 (see
> include/public/arch-arm.h). Can you try to
> On 9 May 2016, at 17:17, Julien Grall wrote:
>
> (CC Shannon, Stefano and Steve)
>
> Hi Lars,
>
> On 09/05/16 16:28, Lars Kurth wrote:
>> Hi all,
>>
>> I added the following sections based on git logs to man pages. Authors are
>> on the CC list and should review and modify (or suggest edit
Newer versions of the QEMU source have replaced the 'stderr' trace
backend with 'log'. This patch adjusts the tools Makefile to test for
the 'log' backend and specify it if it is available.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/Makefile | 4 +++-
1 file changed,
Hello,
> Correct, so the end of the RAM bank would be 0x4200. I am a bit
> surprised that the toolstack does not complain when trying to load the
> kernel at 0x80008000.
> Can you paste the dump of xl -vvv create... ?
$ xl -vvv create dom.cfg
Parsing config from dom.cfg
libxl: debug: libxl_c
Reduced CC list
> On 9 May 2016, at 17:03, George Dunlap wrote:
>
> On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote:
>> Hi all,
>>
>> I added the following sections based on git logs to man pages. Authors are
>> on the CC list and should review and modify (or suggest edits by replying to
>>
Hi all,
as per the RFC at
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03191.html which
received no concrete feedback other than it looks good, I want to call a formal
vote on this proposal. As the proposal affects all subprojects, committers
from the Hypervisor and XAPI tea
On 09/05/16 17:43, Ivan Pavić2 wrote:
Hello Julien,
Hello Ivan,
Julien Grall wrote:
Guest are booting with MMU disabled, so 0x80008000 will be the physical
address.
The toolstack will load the kernel at this physical address. However,
the start of the guest RAM for Xen 4.7 is 0x400
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 09 May 2016 17:29
> To: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org
> Cc: Paul Durrant; Stefano Stabellini; Anthony Perard; Paolo Bonzini
> Subject: [PATCH v2] xen-hvm: ignore background I/O section
Since Xen will correctly handle accesses to unimplemented I/O ports (by
returning all 1's for reads and ignoring writes) there is no need for
QEMU to register backgroud I/O sections.
This patch therefore adds checks to xen_io_add/del so that sections with
memory-region ops pointing at 'unassigned_
Since Xen will correctly handle accesses to unimplemented I/O ports (by
returning all 1's for reads and ignoring writes) there is no need for
QEMU to register backgroud I/O sections.
This patch therefore adds checks to xen_io_add/del so that sections with
memory-region ops pointing at 'unassigned_
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: 09 May 2016 17:39
> To: Paul Durrant; qemu-de...@nongnu.org; xen-de...@lists.xenproject.org
> Cc: Stefano Stabellini; Anthony Perard
> Subject: Re: [PATCH] xen-hvm: ignore background I/O sections
>
>
>
> On 0
On 05/09/2016 09:53 AM, Jan Beulich wrote:
On 09.05.16 at 16:52, wrote:
>> On 05/09/2016 04:08 AM, Jan Beulich wrote:
>> On 09.05.16 at 00:51, wrote:
I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
and Intel Skylake processor (Intel Core i7-6600U)
On 09/05/16 17:37, Zytaruk, Kelly wrote:
> Does Xen have an equivalent function to the Linux dump_stack() function?
>
> I am hitting a panic followed by a reboot and would like to find out where I
> am coming from.
At the point of a crash, the stack should be printed on the console.
Alternativel
On 09/05/2016 18:18, Paul Durrant wrote:
> Since Xen will correctly handle accesses to unimplemented I/O ports (by
> returning all 1's for reads and ignoring writes) there is no need for
> QEMU to register backgroud I/O sections.
>
> This patch therefore adds checks to xen_io_add/del so that sec
Does Xen have an equivalent function to the Linux dump_stack() function?
I am hitting a panic followed by a reboot and would like to find out where I am
coming from.
Thanks,
Kelly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org
Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of
qemu processes"):
> Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of qemu
> processes"):
> > Commit 6ef823fd added '-nodefaults' to the qemu args created by
> > libxl, which is a good step in res
Since Xen will correctly handle accesses to unimplemented I/O ports (by
returning all 1's for reads and ignoring writes) there is no need for
QEMU to register backgroud I/O sections.
This patch therefore adds checks to xen_io_add/del so that sections with
memory-region ops pointing at 'unassigned_
Hello Ivan,
On 09/05/16 11:29, Ivan Pavić2 wrote:
Julien Grail wrote:
You can dump the registers of a vCPU with xenctx.
$PREFIX/lib/xen/bin/xenctx domid
$PREFIX is the path where xen tools have been installed (i.e --prefix on
the configure). The default path is /usr/local/
Thanks for a
flight 93911 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93911/
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 12
Konrad Rzeszutek Wilk wrote:
> OK, but that makes an ELF file. I believe (based on the Booting) you need to
> extract
> the binary code out and also fixup the branch instructions (maybe make
> __Start = 0;?).
> The Booting says:
> - The boot loader is expected to call the kernel image by jumpi
>>> On 06.05.16 at 10:54, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, unsigned long gfn,
> unsigned long mfn,
> unsigned int flags)
> {
> const struct domain_iommu *hd
> -Original Message-
> From: Paul Durrant
> Sent: 09 May 2016 17:02
> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
> Cc: xen-de...@lists.xensource.com; George Dunlap
> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
> > -Original Message-
> > Fro
On 06/05/16 09:12, Jan Beulich wrote:
On 29.04.16 at 11:35, wrote:
>> As discussed on the hackathon, avoid us having to issue security
>> advisories for issues affecting only heavily disaggregated tool stack
>> setups, which no-one appears to use (or else they should step up to get
>> things
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: 09 May 2016 17:18
> To: Paul Durrant; Martin Cerveny
> Cc: xen-de...@lists.xensource.com; George Dunlap
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
> (Xen4.6.1)
>
>
>
> On 09/05/2016 1
On 09/05/2016 18:14, Paul Durrant wrote:
>> -Original Message-
>> From: Paul Durrant
>> Sent: 09 May 2016 17:02
>> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
>> Cc: xen-de...@lists.xensource.com; George Dunlap
>> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server
>> (X
(CC Shannon, Stefano and Steve)
Hi Lars,
On 09/05/16 16:28, Lars Kurth wrote:
Hi all,
I added the following sections based on git logs to man pages. Authors are on
the CC list and should review and modify (or suggest edits by replying to this
thread). I added/updated/added TODO's to:
I do h
>>> On 06.05.16 at 10:54, wrote:
> -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> unsigned int page_count)
> +static void iommu_flush_iotlb_page(struct domain *d, unsigned long gfn,
> + unsigned int page_count)
The new name suggests
On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote:
> Hi all,
>
> I added the following sections based on git logs to man pages. Authors are on
> the CC list and should review and modify (or suggest edits by replying to
> this thread). I added/updated/added TODO's to:
>
> I do have some questions,
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 09 May 2016 14:00
> To: Paolo Bonzini; Martin Cerveny
> Cc: xen-de...@lists.xensource.com; George Dunlap
> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server
>
>>> On 09.05.16 at 16:52, wrote:
> On 05/09/2016 04:08 AM, Jan Beulich wrote:
> On 09.05.16 at 00:51, wrote:
>>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>>> and Intel Skylake processor (Intel Core i7-6600U)
>>>
>>> This kernel is crashing almost in the same way
On Mon, May 09, 2016 at 10:29:09AM +, Ivan Pavić2 wrote:
> Julien Grail wrote:
>
> > You can dump the registers of a vCPU with xenctx.
>
> > $PREFIX/lib/xen/bin/xenctx domid
>
> > $PREFIX is the path where xen tools have been installed (i.e --prefix on
> > the configure). The default path is
On Mon, May 9, 2016 at 3:58 PM, Wei Liu wrote:
> On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote:
>> On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote:
>> > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
>> > wrote:
>> >>
>> >> The scheduling hooks API is now used properly, and no
>>
>
> You need to have appropriate log level set.
>
> Try adding loglvl=all guest_loglvl=all to your xen command line and
> reboot.
>
> Wei.
>
I've enabled all the log level just as you said, but no outputs happen at
HVMOP_altp2m_vcpu_enable_notify section of do_altp2m_op function, so does
that mea
On 09/05/16 16:14, Tim Deegan wrote:
> Hi,
>
> At 14:15 +0100 on 09 May (1462803342), Andrew Cooper wrote:
>> hap_invlpg() is reachable from the instruction emulator, which means
>> introspection and tests using hvm_fep can end up here. As such, crashing the
>> domain is not an appropriate action
Hi all,
I added the following sections based on git logs to man pages. Authors are on
the CC list and should review and modify (or suggest edits by replying to this
thread). I added/updated/added TODO's to:
I do have some questions, to ...
- Konrad/Ross: is there any documentation for xSplice w
flight 93901 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On Thu, Apr 28, 2016 at 11:46 AM, tutu sky wrote:
>
> hi Geoge,
> I don't get your meaning. would you please repeat your question for me in
> order to understand it?
First, please don't top-post.
My meaning was this: You said that running Xen inside of VMWare caused
your host to crash. I said,
On 05/09/2016 04:08 AM, Jan Beulich wrote:
On 09.05.16 at 00:51, wrote:
>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>> and Intel Skylake processor (Intel Core i7-6600U)
>>
>> This kernel is crashing almost in the same way as explained in this
>> thread... But my
On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote:
> On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote:
> > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
> > wrote:
> >>
> >> The scheduling hooks API is now used properly, and no
> >> initialization or de-initialization happen in
> >> al
On Mon, May 9, 2016 at 10:52 AM, Dario Faggioli
wrote:
> On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote:
>> > I don't think things are confusing, neither right now, nor after
>> > this
>> > patch, but I'm open to others' opinion. :-)
>>
>> Hmm, I won't get confused with the comment from now on,
Hi All:
We are researching how to add virtual VTD support for Xen HVM
guest. Current qemu has a basic virtual VTD support for Q35. I'd like to
confirm whether Xen supports Q35 or not. Can we reuse it for Xen? Thanks.
The motivations of adding virtual VTD support for Xen prepare for
1) Shared Vir
On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote:
> > I don't think things are confusing, neither right now, nor after
> > this
> > patch, but I'm open to others' opinion. :-)
>
> Hmm, I won't get confused with the comment from now on, but I'm
> unsure
> if someone else will or not. The tricky thi
On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote:
> On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli
> wrote:
>>
>> The scheduling hooks API is now used properly, and no
>> initialization or de-initialization happen in
>> alloc/free_pdata any longer.
>>
>> In fact, just like it is for Credit2, there
On 21/04/16 15:27, Pali Rohár wrote:
> On Thursday 21 April 2016 15:12:52 Juergen Gross wrote:
>> On 21/04/16 12:57, Pali Rohár wrote:
>>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
> On Tue, Apr 05, 2016 at 07:10:07AM +0200,
On Fri, May 6, 2016 at 2:21 PM, Dario Faggioli
wrote:
> On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote:
>> On 04/05/16 18:21, Dario Faggioli wrote:
>> >
>> > After all, I'm fine with an ASSERT() too, but then I think we
>> > should
>> > add one to the same effect to csched_switch_sched() t
On 29/04/16 10:35, Jan Beulich wrote:
> As discussed on the hackathon, avoid us having to issue security
> advisories for issues affecting only heavily disaggregated tool stack
> setups, which no-one appears to use (or else they should step up to get
> things into shape).
>
> Signed-off-by: Jan Beu
>
>
>
> > I do have a minor comment about the patch, although it is not
> > important at all and it is not really about this patch...
> >
> > >
> > > @@ -614,7 +612,8 @@ rt_deinit(struct scheduler *ops)
> > > {
> > > struct rt_private *prv = rt_priv(ops);
> > >
> > > -kill_timer(prv->repl
On 09/05/16 14:57, Jan Beulich wrote:
On 09.05.16 at 15:15, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -,10 +,13 @@ static void svm_invlpga_intercept(
>>
>> static void svm_invlpg_intercept(unsigned long vaddr)
>> {
>> -struct vcpu *cu
On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote:
> qemu commit 91a097e7 forbids specifying cache mode for empty
> drives. Attempting to create a domain with an empty qdisk cdrom
> drive results in
>
> qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
>cache=writebac
>>> On 09.05.16 at 15:15, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -,10 +,13 @@ static void svm_invlpga_intercept(
>
> static void svm_invlpg_intercept(unsigned long vaddr)
> {
> -struct vcpu *curr = current;
> HVMTRACE_LONG_2D(INVLPG,
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 09 May 2016 14:16
> To: Xen-devel
> Cc: Andrew Cooper; Jan Beulich; Paul Durrant; Wei Liu
> Subject: [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of
> invlpg with segments
>
> The `invlpg
On 09/05/16 14:42, Jan Beulich wrote:
On 09.05.16 at 15:15, wrote:
>> The `invlpg` instruction is documented to take a memory address, and is not
>> documented to suffer faults from segmentation violations.
>>
>> Experimentally, and subsequently confirmed by both Intel and AMD, the
>> instruc
>>> On 09.05.16 at 15:15, wrote:
> The `invlpg` instruction is documented to take a memory address, and is not
> documented to suffer faults from segmentation violations.
>
> Experimentally, and subsequently confirmed by both Intel and AMD, the
> instruction does take into account segment bases,
On 09/05/16 14:15, Andrew Cooper wrote:
> Raising #GP under such circumstances is architecturally wrong.
You should include a reference to the relevant Intel and AMD manuals here.
David
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: Paul Durrant
> CC: Wei Liu
> ---
> xen/arch/x86/hvm/emulat
1 - 100 of 188 matches
Mail list logo
