>>> On 23.11.16 at 00:47, wrote:
> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with
> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to
> perform two (or more, if >32 VCPUs) hypercalls and the logic on the
> hypervisor side is almost the same as the ioreq ha
>>> On 22.11.16 at 17:32, wrote:
> On 22/11/16 13:55, Jan Beulich wrote:
>> The only field modified (and even that conditionally) is the back link.
>> Write only that field, and only when it actually has been written to.
>>
>> Take the opportunity and also ditch the pointless initializer from the
>>> On 22.11.16 at 17:46, wrote:
> On 22/11/16 13:55, Jan Beulich wrote:
>> The only fields modified are EIP, EFLAGS, GPRs, and segment selectors.
>> CR3 in particular is not supposed to be updated.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.
>>> On 22.11.16 at 17:58, wrote:
> On 22/11/16 13:56, Jan Beulich wrote:
>> Whether to write 32 or just 16 bits depends on the D bit of the target
>> CS. The width of the stack pointer to use depends on the B bit of the
>> target SS.
>>
>> Also avoid using the no-fault copying routine.
>>
>> Final
From: Jan Beulich
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.
Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless
1: fix quad word bufioreq handling
2: slightly simplify bufioreq handling
3: ignore direction in bufioreq handling
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
We should not consume the second slot if it didn't get written yet.
Normal writers - i.e. Xen - would not update write_pointer between the
two writes, but the page may get fiddled with by the guest itself, and
we're better off entering an infinite loop in that case.
Reported-by: yanghongke
Signed
There's no point setting fields always receiving the same value on each
iteration, as handle_ioreq() doesn't alter them anyway. Set state and
count once ahead of the loop, drop the redundant clearing of
data_is_ptr, and avoid the meaningless setting of df altogether.
Also avoid doing an unsigned l
There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.
Signed-off-by: Jan Beulich
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -997,6 +997,7 @@ static int
>>> On 23.11.16 at 05:11, wrote:
> flight 102519 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102519/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 20 xtf/test-hvm32-i
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:24
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel
> Subject: [PATCH 1/3] xen: fix quad word bufioreq handling
>
> We should not consume th
On 23/11/2016 09:43, Jan Beulich wrote:
On 23.11.16 at 05:11, wrote:
>> flight 102519 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/102519/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>
The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.
domU.cfg:
'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
domU:
mkfs.e
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:25
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel
> Subject: [PATCH 2/3] xen: slightly simplify bufioreq handling
>
> There's no point set
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:25
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel
> Subject: [PATCH 3/3] xen: ignore direction in bufioreq handling
>
> There's no way to
On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote:
> > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > > The release source did not include those two directories.
> > >
> > > Signed-off-by: Ko
On Mon, Nov 21, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
Tested-by: Olaf Hering
This should go to stable as well.
Olaf
signature.asc
Descri
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v2] xen_disk: split discard input to match
internal representation
Type: series
Message-id: 20161123094914.15675-1-o...@aepfle.de
=== TEST SCRIPT BEGIN ===
#!/bin/bash
>>> On 23.11.16 at 10:49, wrote:
> The invlpg logic isn't (or is no longer) squashing segmentation faults.
>
> I can't recall whether you backported the change that far, but it looks
> as if the test might accidentally been relying on XSA-191 to function on
> older versions of Xen.
That change d
flight 102559 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102559/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 986f790e0184d4bf575462077378e14fa9f85aa9
baseline version:
xen 58bd
Dear all,
Building latest XEN master branch
(58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using
the same yocto as here
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I've
faced following issue:
Maximum error count (200) exceeded
/home/aanisov/DEV
>>> On 23.11.16 at 10:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 November 2016 09:24
>>
>> We should not consume the second slot if it didn't get written yet.
>> Normal writers - i.e. Xen - would not update write_pointer between the
>> two writes, but the page may get
Hi,
static DECLARE_BITMAP(vmid_mask, MAX_VMID);
>>
>> void p2m_vmid_allocator_init(void)
>> {
>> +unsigned int cpu;
>> +
>> set_bit(INVALID_VMID, vmid_mask);
>> +
>> +max_vmid = MAX_VMID;
>>
>
> max_vmid is only declared for ARM64 and will break compilation for ARM32.
> Please try
The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.
domU.cfg:
'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
domU:
mkfs.e
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 10:36
> To: Paul Durrant
> Cc: Anthony Perard ; Stefano Stabellini
> ; xen-devel ;
> qemu-de...@nongnu.org
> Subject: RE: [PATCH 1/3] xen: fix quad word bufioreq handling
>
> >>> On 23.11.16 at 10
>>> On 23.11.16 at 11:29, wrote:
> Building latest XEN master branch
> (58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using
> the same yocto as here
> https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
> I've
> faced following issue:
>
> Maximum error
Ping.
On Fri, Nov 18, Olaf Hering wrote:
> On Fri, Nov 18, Olaf Hering wrote:
>
> > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
> > +if (!blk_split_discard(ioreq, req->sector_number,
> > req->nr_sectors)) {
> > +goto err;
>
> How is error hand
On 23/11/16 08:27, Jan Beulich wrote:
On 22.11.16 at 17:32, wrote:
>> On 22/11/16 13:55, Jan Beulich wrote:
>>> The only field modified (and even that conditionally) is the back link.
>>> Write only that field, and only when it actually has been written to.
>>>
>>> Take the opportunity and al
> Looking at the source I see that this statement gets included for
> x86 only. Are you perhaps doing a cross build of the ARM tools
> on an x86 host?
Indeed. I do.
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lis
On Wed, Nov 23, Olaf Hering wrote:
> > > +if (!blk_split_discard(ioreq, req->sector_number,
> > > req->nr_sectors)) {
> > > +goto err;
> > How is error handling supposed to work here?
In the guest the cmd is stuck, instead of getting an IO error:
[ 91.966404] mkfs.ext4
This would be benign if there wasn't the zero-extending side effect of
32-bit operations in 64-bit mode.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -653,6 +653,21 @@ int main(int argc, char **argv)
prin
>>> On 23.11.16 at 11:45, wrote:
> No, if QEMU is using a default ioreq server (i.e. the legacy way of doing
> things) then it's vulnerable to the guest messing with the rings and I'd
> forgotten that migrated-in guests from old QEMUs also end up using the
> default
> server, so I guess this i
On 11/23/2016 04:39 AM, Olaf Hering wrote:
> The guest sends discard requests as u64 sector/count pairs, but the
> block layer operates internally with s64/s32 pairs. The conversion
> leads to IO errors in the guest, the discard request is not processed.
>
> domU.cfg:
> 'vdev=xvda, format=qcow
Contains items that at some point need to be addressed.
The items do not directly affect governance.pandoc
Signed-off-by: Lars Kurth
---
governance.todo | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 governance.todo
diff --git a/governance.todo b/governance.t
List of changes
- Added Goal: Local Decision Making
- Split roles into project wide and sub-project specific roles
- Added new roles: Community Manager, Security Response Team, Leadership Team
- Added RTC Policy
- Added +2 ... -2 scheme for expressing opinions more clearly
- Clarified lazy consensu
Added TOC
Re-arranged sections compared to previous version of document
Added new anchors where needed
Split Roles section into two sections
The actual content was not changed (with the exception of minor
typos that I spotted)
Signed-off-by: Lars Kurth
---
governance.pandoc | 207 ++
THIS IS VERSION 5 OF THIS PATCH AND WE ARE READY FOR FORMAL VOTING, UNLESS
SOMEONE OBJECTS. PEOPLE LISTED AS COMMITTERS IN
- https://xenproject.org/developers/teams/hypervisor.html
- https://xenproject.org/developers/teams/xapi.html
PLEASE VOTE BEFORE DEC 2nd
I made some significant proposed chang
Make the libxl ACPI support build configurable by the same config
option as the hypervisor side support.
Signed-off-by: Andrii Anisov
---
tools/libxl/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f5053a0..a4e9319 10
On November 23, 2016 5:14:00 AM EST, Wei Liu wrote:
>On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote:
>> > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk
>wrote:
>> > > The release source did not inc
Am 23.11.2016 um 12:40 hat Eric Blake geschrieben:
> On 11/23/2016 04:39 AM, Olaf Hering wrote:
> > The guest sends discard requests as u64 sector/count pairs, but the
> > block layer operates internally with s64/s32 pairs. The conversion
> > leads to IO errors in the guest, the discard request is
Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.
The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the union with Elf64_Shdr d
EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to
compare it against xen_vcpu_id mapping, not the Linux cpu id.
Suggested-by: Radim Krcmar
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/events/events_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
flight 68084 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68084/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
68048
test-amd64-
From: Roger Pau Monne
Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
guests, that corrupted the section headers array due to the padding
introduced by the elf_shdr union.
The Elf section header array on 32bit should be accessible as an array of
Elf32_Shdr elements, and the
Hello,
On 23/11/16 12:25, Andrii Anisov wrote:
Make the libxl ACPI support build configurable by the same config
option as the hypervisor side support.
This will not work because Kconfig support only exists for the hypervisor.
Furthermore, people may want to disable ACPI for the host but stil
This run is configured for baseline tests only.
flight 68083 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68083/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl19 guest-start/debian.repe
> This will not work because Kconfig support only exists for the hypervisor.
So I totally confused where CONFIG_ARM_64 is defined for tools.
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 23/11/16 10:38, Bhupinder Thakur wrote:
Hi,
Hi Bhupinder,
Can you configure your e-mail client to use ">" to quote the previous
answer? Using tab makes the mail quite confusing. Thank you.
static DECLARE_BITMAP(vmid_mask, MAX_VMID);
void p2m_vmid_allocator_init(void)
On Wed, Nov 23, 2016 at 03:03:54PM +0200, Andrii Anisov wrote:
> > This will not work because Kconfig support only exists for the hypervisor.
>
> So I totally confused where CONFIG_ARM_64 is defined for tools.
>
It is defined in config/arm64.mk, which is included by various
makefiles.
> Sincer
On Wed, Nov 23, 2016 at 12:27:38PM +, Roger Pau Monne wrote:
> Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit
> guests, that corrupted the section headers array due to the padding
> introduced by the elf_shdr union.
>
> The Elf section header array on 32bit should be acc
On 11/23/2016 03:09 AM, Jan Beulich wrote:
On 23.11.16 at 00:47, wrote:
>> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with
>> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to
>> perform two (or more, if >32 VCPUs) hypercalls and the logic on the
>> hy
Stefano,
Please see my answers below:
>
> Thank you for the document, I think is a very good start. I also see the
> need for this framework. Please add more details about the proposed
> interface (Xen API, hypercalls, etc) in the next version; I am looking
> forward to it.
We will come up with t
>>> On 23.11.16 at 14:33, wrote:
> On 11/23/2016 03:09 AM, Jan Beulich wrote:
> On 23.11.16 at 00:47, wrote:
>>> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with
>>> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to
>>> perform two (or more, if >32 VCPUs
> It is defined in config/arm64.mk, which is included by various
> makefiles.
As I got, it is included by Config.mk which consequently included by
different makefiles in hypervisor, tools, docs, stubdom.
It looks like a piece of legasy configuration code, I see moves of
CONFIG_ options from it to K
Dear all,
Andrii, thanks for the remark - I'll rework this patch.
Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6
Looks like used patches for Xen should be described more briefly:
1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch -
On Wed, Nov 23, 2016 at 03:59:54PM +0200, Andrii Anisov wrote:
> > It is defined in config/arm64.mk, which is included by various
> > makefiles.
> As I got, it is included by Config.mk which consequently included by
> different makefiles in hypervisor, tools, docs, stubdom.
> It looks like a piece
> But before you write any code, let me try to understand the real issue
> first: you're trying to cross-build ARM tools on x86, but x86
> iasl doesn't support ARM ACPI definition(s), right?
Well, as I stated here [1], I'm pretty far from ACPI and understanding
of what's going wrong with the compil
On 11/23/2016 08:58 AM, Jan Beulich wrote:
On 23.11.16 at 14:33, wrote:
>> On 11/23/2016 03:09 AM, Jan Beulich wrote:
>> On 23.11.16 at 00:47, wrote:
I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with
XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack
This patch introduces a design proposal for an interface to used by
guest PV drivers or agents to convey statistics to a monitoring agent
running in a toolstack domain.
Signed-off-by: Paul Durrant
---
RFC at the moment since this is a first draft and it is not yet
prototyped
---
docs/designs/pv_
On Tue, Nov 22, 2016 at 06:51:27AM -0700, Jan Beulich wrote:
> 1: limit writes to incoming TSS during task switch
> 2: limit writes to outgoing TSS during task switch
> 3: correct error code writing during task switch
>
> Signed-off-by: Jan Beulich
>
Release-acked-by: Wei Liu
On Tue, Nov 22, 2016 at 07:09:04AM -0700, Jan Beulich wrote:
> These aren't outright bug fixes, so aren't strictly candidates for 4.8,
> but I think they're still worthwhile to consider.
>
> 1: simplify DstBitBase handling code
> 2: in_longmode() should not ignore ->read_msr() errors
>
> Signed-o
Iurii,
About the following:
> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.
Please review this [1] thread.
[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg0192
Dear Iurii,
Following:
> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.
Is not needed.
The issue does not appear with the current master HEAD.
Sincerely,
Andrii Anisov.
On Wed, No
>>> On 23.11.16 at 15:05, wrote:
> But before you write any code, let me try to understand the real issue
> first: you're trying to cross-build ARM tools on x86, but x86
> iasl doesn't support ARM ACPI definition(s), right?
No, the problem is that Shannon has broken cross builds of libacpi's
mk_d
Dear Andrii and all,
On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov
wrote:
> Iurii,
>
> About the following:
>
> > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix
> > build issue, described here [2]. I haven't found any better solution
> except
> > this one.
>
> Please re
On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:
> > But before you write any code, let me try to understand the real issue
> > first: you're trying to cross-build ARM tools on x86, but x86
> > iasl doesn't support ARM ACPI definition(s), right?
> Well, as I stated here [1], I'm prett
Hi Wei,
On 23/11/16 14:29, Wei Liu wrote:
On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:
But before you write any code, let me try to understand the real issue
first: you're trying to cross-build ARM tools on x86, but x86
iasl doesn't support ARM ACPI definition(s), right?
Well
On Wed, Nov 23, 2016 at 02:34:04PM +, Julien Grall wrote:
> Hi Wei,
>
> On 23/11/16 14:29, Wei Liu wrote:
> >On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote:
> >>>But before you write any code, let me try to understand the real issue
> >>>first: you're trying to cross-build ARM t
On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
> From Laszlo:
> " change the catch-all (*) to GCC5, from GCC44
> - remove the (5.*.*) pattern from GCC49
> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
> earlier to exit with an error message / failure (those compiler
> ve
On 11/23/16 15:55, Laszlo Ersek wrote:
> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
>> From Laszlo:
>> " change the catch-all (*) to GCC5, from GCC44
>> - remove the (5.*.*) pattern from GCC49
>> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>> earlier to exit with an
On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote:
> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
> > From Laszlo:
> > " change the catch-all (*) to GCC5, from GCC44
> > - remove the (5.*.*) pattern from GCC49
> > - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>
On 23/11/16 14:00, Iurii Mykhalskyi wrote:
Dear all,
Hello Iurii,
Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6
Can you explain why you want to impose a specific version of Xen to the
user of this board?
If Xen does not work out-of-box o
Hello Andrii,
On 23/11/16 14:12, Andrii Anisov wrote:
But before you write any code, let me try to understand the real issue
first: you're trying to cross-build ARM tools on x86, but x86
iasl doesn't support ARM ACPI definition(s), right?
Well, as I stated here [1], I'm pretty far from ACPI and
On 22.11.16 21:36, Julien Grall wrote:
> On 22/11/16 19:06, Stefano Stabellini wrote:
>> On Mon, 21 Nov 2016, Julien Grall wrote:
>>> On 21/11/2016 21:13, Edgar E. Iglesias wrote:
On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> On Mon, 21 Nov 2016, Edgar E. Iglesias w
On Wed, Nov 23, 2016 at 02:14:27PM +, Paul Durrant wrote:
> This patch introduces a design proposal for an interface to used by
> guest PV drivers or agents to convey statistics to a monitoring agent
> running in a toolstack domain.
>
Hey Paul!
Thank you for posting this, adding on the CC so
Hello Artem,
On 23/11/16 15:10, Artem Mygaiev wrote:
On 22.11.16 21:36, Julien Grall wrote:
I'm just curious - is it really have to be UART? can it be a PV TTY
device(s)? Wouldn't it be better to avoid unneeded HW emulation and just
provide "serial" function?
There is a couple of usecase where
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 23 November 2016 15:08
> To: Paul Durrant ; annie...@oracle.com;
> adnan.mishe...@oracle.com
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interfac
Introduce generate_exception() for unconditional exception generation, and
replace existing uses. Both generate_exception() and generate_exception_if()
are updated to make their error code parameters optional, which removes the
use of the -1 sentinal.
The ioport_access_check() check loses the pre
The current code to set up emulation state is ad-hoc and error prone.
* Consistently zero all emulation state structures.
* Avoid explicitly initialising some state to 0.
* Explicitly identify all input and output state in x86_emulate_ctxt. This
involves rearanging some fields.
* Have x86_
This is partly RFC as there is a whole lot of rebasing happened recently and I
haven't run thorough tests yet.
This is the quantity of changes required to fix some edgecases in XSA-191
which were ultimately chosen not to go out in the security fix. The main
purpose of this series is to fix emulat
Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and
use this instead of hvm_inject_page_fault() from emulation codepaths.
Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
CC: Tim
* Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
very closely related.
* Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
and when to use them.
No functional change.
Signed
No functional change at this point, but this is a prerequisite for forthcoming
functional changes.
Make vmx_get_segment_register() private to vmx.c like all the other Vendor
get/set functions.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: George Dunlap
---
CC: Jun Nakajima
On 14/11/16 17:35, Andre Przywara wrote:
Hi,
Hi Andre,
On 01/11/16 15:13, Julien Grall wrote:
On 28/09/2016 19:24, Andre Przywara wrote:
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to
Intel VT-x and AMD SVM provide access to the full segment descriptor cache via
fields in the VMCB/VMCS. However, the bits which are actually checked by
hardware and preserved across vmentry/exit are inconsistent, and the vendor
accessor functions perform inconsistent modification to the raw values
and move it to live with the other x86_event infrastructure in x86_emulate.h.
Switch it and x86_event.error_code to being signed, matching the rest of the
code.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
CC: Jun Nakajima
CC: Kevin Tian
CC: Boris Ostrovsky
CC: Suravee S
The x86 emulator needs to gain an understanding of interrupts and exceptions
generated by its actions. The naming choice is to match both the Intel and
AMD terms, and to avoid 'trap' specifically as it has an architectural meaning
different to its current usage.
While making this change, make oth
The emulator needs to gain an understanding of interrupts and exceptions
generated by its actions.
Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
are visible to the emulator. This removes the need for the
inject_{hw,sw}_interrupt() hooks, which are dropped and repla
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 23 November 2016 15:08
> To: Paul Durrant ; annie...@oracle.com;
> adnan.mishe...@oracle.com
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interfac
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Paul Durrant
CC: Tim Deegan
---
xen/arch/x86/hvm/emulate.c| 6 ++---
xen/arch/x86/hvm/hvm.c| 56 +--
xen/arch/x86/mm/shadow/common.c | 8 +++---
xen/
Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
to inject the pagefault themselves.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
CC: Tim Deegan
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/emulate.c|
All system segments (GDT/IDT/LDT and TR) describe a linear address and limit,
and act similarly to user segments. However all current uses of these tables
in the emulator opencode the address calculations and limit checks. In
particular, no care is taken for access which wrap around the 4GB or
no
With hvm_virtual_to_linear_addr() capable of doing proper system-segment
relative memory accesses, avoid open-coding the address and limit calculations
locally.
When a table spans the 4GB boundary (32bit) or non-canonical boundary (64bit),
segmentation errors are now raised. Previously, the use o
The functions use linear addresses, not virtual addresses, as no segmentation
is used. (Lots of other code in Xen makes this mistake.)
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Paul Durrant
CC: Tim Deegan
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/emulate.c| 12
Hello Julien,
> The ACPI support is pretty much contained in a single file and I am not sure
> you will win much space.
> Can you explain why the ACPI guest support should be optional?
This would increase the system configurability and would let one
shrink a system to a minimal footprint with req
which is filled with pagefault information should one occur.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Paul Durrant
CC: Tim Deegan
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/emulate.c| 8 ---
xen/arch/x86/hvm/hvm.c
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> ; Wei Liu
> Subject: [PATCH 01/15] x8
On Wed, Nov 23, 2016 at 03:38:44PM +, Andrew Cooper wrote:
> * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
> * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it
flight 102522 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102522/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-3 65 leak-check/check fail in 102500 pass in 102522
test-amd64-amd64-xl-qemut-stubdo
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Tim (Xen.org) ; George Dunlap
> ; Paul Durrant
> Subject: [PATCH 02/15] x86/emul: Simplfy emulation state setup
>
> The curre
1 - 100 of 201 matches
Mail list logo
