flight 59044 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59044/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3864 capture-logs !broken [st=!broken!]
build-i
flight 59041 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
build-armhf-xsm
On 07/01/15 16:01, Konrad Rzeszutek Wilk wrote:
>> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
>> index ed2bd38..651b338 100644
>> --- a/tools/libxl/libxl_x86.c
>> +++ b/tools/libxl/libxl_x86.c
>> @@ -5,8 +5,8 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>
flight 59040 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2
fail REGR. vs. 58958
flight 59042 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59042/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
seabios
flight 59039 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd "netfilter: bridge:
forward IPv6 fragmented packets" introduced a new function
br_validate_ipv6 which take a reference on the inet6 device. Although,
the reference is not released at the end.
This will result to the impossibility to destroy any n
On 03/07/15 17:25, Paul Durrant wrote:
> By limiting hvmemul_do_io_addr() to reps falling within the page on which
> a reference has already been taken, we can guarantee that calls to
> hvm_copy_to/from_guest_phys() will not hit the HVMCOPY_gfn_paged_out
> or HVMCOPY_gfn_shared cases. Thus we can r
On 03/07/15 17:25, Paul Durrant wrote:
> ...in hvmemul_read/write()
>
> Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
> to reduce code duplication.
>
> NOTE: This patch also introduces a change in 'chunking' around a page
> boundary. Previously (for example) an 8 b
On 01/07/15 19:09, Ed White wrote:
> Add the remaining routines required to support enabling the alternate
> p2m functionality.
>
> Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.
From: Liang Li
Date: Sat, 4 Jul 2015 03:33:00 +0800
> There are two duplicated xenvif_zerocopy_callback() definitions.
> Remove one of them.
>
> Signed-off-by: Liang Li
You really need to fix the date on your computer.
If your date is in the future, as your's is, then your patch appears
out-
On 01/07/15 19:09, Ed White wrote:
> Add a flag to indicate that a memory event occurred in an alternate p2m
> and a field containing the p2m index. Allow any event response to switch
> to a different alternate p2m using the same flag and field.
>
> Modify p2m_memory_access_check() to handle altern
The code in hvmemul_do_io() that tracks large reads or writes, to avoid
re-issue of component I/O, is defeated by accesses across a page boundary
because it uses physical address. The code is also only relevant to memory
mapped I/O to or from a buffer.
This patch re-factors the code and moves it i
By removing the HVMIO_dispatched state and making all pending emulations
(i.e. all those not handled by the hypervisor) use HVMIO_awating_completion,
various code-paths can be simplified.
The completion case for HVMIO_dispatched can also be trivally removed
from hvmemul_do_io() as it was already u
By removing the calls in hvmemul_do_io() (which is replaced by a single
assignment) and hvm_complete_assist_request() (which is replaced by a
call to hvm_process_portio_intercept() with a suitable set of ops) then
hvm_io_assist() can be moved into hvm.c and made static (and hence be a
candidate for
Use an ioreq_t rather than open coded state, size, dir and data fields
in struct hvm_vcpu_io. This also allows PIO completion to be handled
similarly to MMIO completion by re-issuing the handle_pio() call.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Reviewed-by: Andrew Cooper
-
The state of in-flight I/O and how its completion will be handled are
logically separate and conflating the two makes the code unnecessarily
confusing.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c| 44 +
Emulation request status is already covered by STATE_IOREQ_XXX values so
just use those. The mapping is:
HVMIO_none-> STATE_IOREQ_NONE
HVMIO_awaiting_completion -> STATE_IOREQ_READY
HVMIO_completed -> STATE_IORESP_READY
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Acked
If memory mapped I/O is 'chunked' then the I/O must be re-emulated,
otherwise only the first chunk will be processed. This patch makes
sure all I/O from a buffer is re-emulated regardless of whether it
is a read or a write.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Acked-by: Jan Beulich
Revie
On 01/07/15 19:09, Ed White wrote:
> The existing ept_set_entry() and ept_get_entry() routines are extended
> to optionally set/get suppress_ve and renamed. New ept_set_entry() and
> ept_get_entry() routines are provided as wrappers, where set preserves
> suppress_ve for an existing entry and sets
On 01/07/15 19:09, Ed White wrote:
> From: Ravi Sahita
>
> Signed-off-by: Ravi Sahita
> ---
> xen/arch/x86/hvm/emulate.c | 12 +++--
> xen/arch/x86/hvm/vmx/vmx.c | 30 +
> xen/arch/x86/x86_emulate/x86_emulate.c | 48
> +
El 03/07/15 a les 18.19, David Vrabel ha escrit:
> On 03/07/15 12:34, Roger Pau Monne wrote:
>>
>> And for the FreeBSD part:
>
> Have you thought at all about what the Linux support for this mode would
> look like?
>
> I started briefly looking today but don't really have time to look into
> it p
On 01/07/15 19:09, Ed White wrote:
> Implement and hook up the code to enable VMX support of VMFUNC and #VE.
>
> VMFUNC leaf 0 (EPTP switching) emulation is added in a later patch.
>
> Signed-off-by: Ed White
Reviewed-by: Andrew Cooper
(You are also going to need an ack/review from a VMX mainta
By limiting hvmemul_do_io_addr() to reps falling within the page on which
a reference has already been taken, we can guarantee that calls to
hvm_copy_to/from_guest_phys() will not hit the HVMCOPY_gfn_paged_out
or HVMCOPY_gfn_shared cases. Thus we can remove the retry logic (added
by c/s 82ed8716b "
This patch re-works the dpci portio intercepts so that they can be unified
with standard portio handling thereby removing a substantial amount of
code duplication.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c |2
Building on the previous patch, this patch restricts portio port numbers
to uint16_t in registration/relocate calls and portio_action_t. It also
changes portio sizes to unsigned int which then allows the io_handler
size field to reduce to an unsigned int.
Signed-off-by: Paul Durrant
Cc: Keir Fras
...in hvmemul_read/write()
Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
to reduce code duplication.
NOTE: This patch also introduces a change in 'chunking' around a page
boundary. Previously (for example) an 8 byte access at the last
byte of a page would g
This patch series re-works much of the code involved in emulation of port
and memory mapped I/O for HVM guests.
The code has become very convoluted and, at least by inspection, certain
emulations will apparently malfunction.
The series is broken down into 16 patches (which are also available in
m
The addition of commit 2df1aa01 "x86/hvm: remove hvm_io_pending() check
in hvmemul_do_io()" causes a problem in migration because I/O that was
caught by the test of vcpu_start_shutdown_deferral() in
hvm_send_assist_req() is now considered completed rather than requiring
a retry.
This patch fixes t
It's clear from the following check in hvmemul_rep_movs:
if ( sp2mt == p2m_mmio_direct || dp2mt == p2m_mmio_direct ||
(sp2mt == p2m_mmio_dm && dp2mt == p2m_mmio_dm) )
return X86EMUL_UNHANDLEABLE;
that mmio <-> mmio copy is not handled. This means the code in the
stdvga mmio i
When memory mapped I/O is range checked by internal handlers, the length
of the access should be taken into account.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/intercept.c | 23 ---
xen/include/asm-x86/hvm/
The implementation of mmio and portio intercepts is unnecessarily different.
This leads to much code duplication. This patch unifies much of the
intercept handling, leaving only distinct handlers for stdvga mmio and dpci
portio. Subsequent patches will unify those handlers.
Signed-off-by: Paul Dur
...from unsigned long to unsigned int
A 64-bit length is not necessary, 32 bits is enough.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Reviewed-by: Andrew Cooper
---
xen/arch/x86/hvm/hpet.c |4 ++--
xen/arch/x86/hvm/vioapic.c|4 ++--
On 01/07/15 19:09, Ed White wrote:
> Add the basic data structures needed to support alternate p2m's and
> the functions to initialise them and tear them down.
>
> Although Intel hardware can handle 512 EPTP's per hardware thread
> concurrently, only 10 per domain are supported in this patch for
>
At 07:52 -0400 on 24 Jun (1435132373), Boris Ostrovsky wrote:
> On 06/24/2015 06:14 AM, Roger Pau Monné wrote:
> > El 24/06/15 a les 12.05, Jan Beulich ha escrit:
> > On 24.06.15 at 11:47, wrote:
> >>> What needs to be done (ordered by priority):
> >>>
> >>> - Clean up the patches, this patc
On 03/07/15 12:34, Roger Pau Monne wrote:
>
> And for the FreeBSD part:
Have you thought at all about what the Linux support for this mode would
look like?
I started briefly looking today but don't really have time to look into
it properly. I do think we want to use as much of the native/HVM co
Ian Campbell writes ("Re: [PATCH OSSTEST v4] mg-all-branch-statuses: Show how
up to date each branch is"):
> Should it not be:
>
> BRANCHES=all-branch-statuses ./cr-for-branches . -w ./cr-maintjobs ''
> which ends up calling
> ./cr-maintjobs all-branch-status
> which in turn calls (from a "case $
On Fri, 2015-07-03 at 18:39 +0300, Vitaly Chernooky wrote:
> On Thu, Jul 2, 2015 at 1:48 PM, Dario Faggioli
> wrote:
> Actually, we don't even have mutexes _within_ the hypervisor,
> so I
> struggle a bit to figure out how it would be useful to offer a
> similar
On Fri, 2015-07-03 at 16:25 +0100, Ian Jackson wrote:
> Jennifer Herbert writes ("[Xen-devel] [PATCH 6/7] libxc: Fix misleading use
> of strncpy code in build_hvm_info()"):
> > hvm_info->signature is not a string, but an 64 bit int, and is not
> > NULL terminated. The use of strncpy to populate i
On Fri, 2015-07-03 at 15:43 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v4] mg-all-branch-statuses: Show how
> up to date each branch is"):
> > On Fri, 2015-07-03 at 14:40 +0100, Ian Jackson wrote:
> > > Do you want to provide a cron job to run this weekly, or something ?
On Fri, 2015-07-03 at 16:17 +0100, Ian Jackson wrote:
> Jennifer Herbert writes ("[Xen-devel] [PATCH 4/7] libxc: Prevent
> dereferencing NULL pointers returned from xc_dom_allocate()"):
> > The return from xc_dom_allocate is not checked for a NULL value.
> > This patch fixes this, causing it to re
On 03/07/15 16:50, Ian Campbell wrote:
> On Fri, 2015-07-03 at 16:47 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/7] libxc: fix uninitialized
>> variable in xc_cpuid_pv_policy()"):
>>> On Fri, 2015-07-03 at 16:15 +0100, Ian Jackson wrote:
Unfortunately xc_cpuid_
This uses the dt_for_each_{irq_map,range} helpers to map the interrupt
and child MMIO regions to dom0. Since PCI busses are enumerable these
resources may not be otherwise described in the DT (although they can
be).
Although PCI is the only bus we handle this way the code should be
generic enough
This provides specific handlers for the PCI bus relating to matching
and translating. It's mostly similar to the defaults but includes some
additional error checks and other PCI specific bits.
There are some subtle differences in how the generic code vs. the pci
specific code here will handle bugg
The code in the callbacks for dt_for_each_irq_map and
dt_for_each_range is very similar to the code in handle_device for
each non-pci device.
In fact the only major difference is that the irq callback needs to
call irq_set_spi_type in the PCI case. Refactor into a
map_dt_irq_to_domain callback whi
This series adds parsing of the DT ranges and interrupt-map properties
for PCI devices, these contain the MMIOs and IRQs used by children on
the bus. This replaces the specific mapping stuff on xgene.
This is a quick respin based on Julien's comments on v4 which were
missed in v5.
I only tested o
This is only needed if we are giving the IRQ to dom0 (as opposed to
setting it up for passthrough due to xen,passthrough property). There
is already a call to vgic_reserve_virq inside the if ( need_mapping ),
so drop this one.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v4: New pa
This function iterates over a nodes interrupt-map property and calls a
callback for each interrupt. For now it only supplies the translated
IRQ since my use case has no need of e.g. child unit address. These
can be added as needed by any future users.
This follows much the same logic as dt_irq_map
This function iterates over a node's ranges property and calls a
callback for each region. For now it only supplies the MMIO range (in
terms of CPU addresses, i.e. already translated).
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
v6: Treat !0 as an error not < 0 for the callback.
--
On Fri, 2015-07-03 at 16:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/7] libxc: fix uninitialized
> variable in xc_cpuid_pv_policy()"):
> > On Fri, 2015-07-03 at 16:15 +0100, Ian Jackson wrote:
> > > Unfortunately xc_cpuid_pv_policy doesn't return an error code. I
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/schedule.c | 64 -
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index ecf1545..26e
The function is called both when we want to remove a cpu
from a cpupool, and during cpu teardown, for suspend or
shutdown. If, however, the boot cpu (cpu 0, most of the
times) is not present in the default cpupool, during
suspend or shutdown, Xen crashes like this:
root@Zhaman:~# xl cpupool-cpu-
And this time, do it right. In fact, a similar change was
attempted in 93be8285a79c6 ("cpupools: update domU's node-affinity
on the cpupool_unassign_cpu() path"). But that was buggy, and got
reverted with 8395b67ab0b8a86.
However, even though reverting was the right thing to do, it
remains true th
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/schedule.c | 48 +---
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 26e8430..e83c
More specifically, this time, of cases when we try to shut the system down or
suspend it in the following situations:
- when the boot cpu (i.e., most of the times, cpu 0) is not assigned to any
cpupool,
- when a (non default) cpupool only has one cpu (and that is not the boot
cpu).
In both
Ian Campbell writes ("Re: [Xen-devel] [PATCH 5/7] libxc: Removing dead code
from xc_dom_allocate()"):
> I'd be ok with either leaving this as is (and tagging CID 1055188 as
> intentioanl) or adding the null initialiser as you suggested in your
> "However: "
I would be happy with either of those.
Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/7] libxc: fix uninitialized
variable in xc_cpuid_pv_policy()"):
> On Fri, 2015-07-03 at 16:15 +0100, Ian Jackson wrote:
> > Unfortunately xc_cpuid_pv_policy doesn't return an error code. I
> > think it needs to. So that's rather a yak.
>
> I was ab
On Fri, 2015-07-03 at 16:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 5/7] libxc: Removing dead code
> from xc_dom_allocate()"):
> > On Fri, 2015-07-03 at 16:24 +0100, Ian Jackson wrote:
> > > Jennifer Herbert writes ("[Xen-devel] [PATCH 5/7] libxc: Removing dead
>
Ian Campbell writes ("Re: [Xen-devel] [PATCH 7/7] libxc: Prevent NULL pointer
dereference in stdiostream_vmessage()"):
> On Fri, 2015-07-03 at 16:29 +0100, Ian Jackson wrote:
> > I think it would be best, in this error case, to explicitly note that
> > date/time conversion failed, by printing (say
On Thu, Jul 2, 2015 at 1:48 PM, Dario Faggioli
wrote:
> On Thu, 2015-07-02 at 12:48 +0300, Vitaly Chernooky wrote:
> > Hi all!
> >
> Hi,
> >
> > I have theoretical question.
> >
> Great, I love theoretical stuff! :-P
> >
> > What do you think about porting futexes or binder to XEN?
> >
> Ouch...
On Fri, 2015-07-03 at 16:15 +0100, Ian Jackson wrote:
> Jennifer Herbert writes ("[Xen-devel] [PATCH 1/7] libxc: fix uninitialized
> variable in xc_cpuid_pv_policy()"):
> > If xc_domain_get_guest_width were to fail, guest_width is not set, and
> > hence guest_64bit becomes undefined.
> > Fix is to
On Fri, 2015-07-03 at 16:29 +0100, Ian Jackson wrote:
> Jennifer Herbert writes ("[Xen-devel] [PATCH 7/7] libxc: Prevent NULL pointer
> dereference in stdiostream_vmessage()"):
> > Unlikely that it may seem localtime_r could fail, which would result in a
> > null pointer dereference. In this case
El 03/07/15 a les 13.35, Roger Pau Monne ha escrit:
> Change the physical memory address of the special pages when there are no
> emulated devices. On HVM guests the special pages have always been reserved
> so that they end at the 0xff000 pfn, but there are some problems with this
> approach when
On Fri, 2015-06-26 at 16:54 +0100, Ian Campbell wrote:
> On Fri, 2015-06-26 at 16:43 +0100, Julien Grall wrote:
> > This field have been set but not used since Xen 4.5. Slim down Xen by
> > about 4K by removing it.
> >
> > Also fix comment coding style.
> >
> > Signed-off-by: Julien Grall
> > --
Ian Campbell writes ("Re: [Xen-devel] [PATCH 5/7] libxc: Removing dead code
from xc_dom_allocate()"):
> On Fri, 2015-07-03 at 16:24 +0100, Ian Jackson wrote:
> > Jennifer Herbert writes ("[Xen-devel] [PATCH 5/7] libxc: Removing dead code
> > from xc_dom_allocate()"):
> > > The only place that jum
On Fri, 2015-07-03 at 16:24 +0100, Ian Jackson wrote:
> Jennifer Herbert writes ("[Xen-devel] [PATCH 5/7] libxc: Removing dead code
> from xc_dom_allocate()"):
> > The only place that jumps to 'err:' does so because !dom, which is
> > rechecked in 'err:'. This patch simplifies, giving the same re
Jennifer Herbert writes ("[Xen-devel] [PATCH 3/7] libxc: Fix uninitialized
valiables in xc_cpuid_hvm_policy()"):
> If xc_hvm_param_get fails, is_pae and/or is_nestedhvm are left undefined.
> This patch Indicates error and defaults to false.
I think my comments on xc_cpuid_pv_policy apply to this
Jennifer Herbert writes ("[Xen-devel] [PATCH 7/7] libxc: Prevent NULL pointer
dereference in stdiostream_vmessage()"):
> Unlikely that it may seem localtime_r could fail, which would result in a
> null pointer dereference. In this case, one can simply just skip logging the
> date/time, and loggin
On Fri, 2015-07-03 at 16:15 +0100, Julien Grall wrote:
> >> The other caller of dt_irq_translate returns an error when ret is not 0.
> >> I would do the same here.
> >
> > dt_device_get_irq just returns the value of dt_irq_translate directly.
>
> But the caller of dt_device_get_irq is treating e
Jennifer Herbert writes ("[Xen-devel] [PATCH 2/7] libxc: Use const pointer in
local_file_dump()"):
> By adding the const keyword, it is clearer to people and static analysis
> tools that no changes to the data are to be made.
Would it be wrong for a future patch to add a field to dump_args which
On 30/06/15 14:05, Paul Durrant wrote:
> The code in hvmemul_do_io() that tracks large reads or writes, to avoid
> re-issue of component I/O, is defeated by accesses across a page boundary
> because it uses physical address. The code is also only relevant to memory
> mapped I/O to or from a buffer.
On 30/06/15 14:05, Paul Durrant wrote:
> If memory mapped I/O is 'chunked' then the I/O must be re-emulated,
> otherwise only the first chunk will be processed. This patch makes
> sure all I/O from a buffer is re-emulated regardless of whether it
> is a read or a write.
>
> Signed-off-by: Paul Durr
Jennifer Herbert writes ("[Xen-devel] [PATCH 6/7] libxc: Fix misleading use of
strncpy code in build_hvm_info()"):
> hvm_info->signature is not a string, but an 64 bit int, and is not
> NULL terminated. The use of strncpy to populate it is inappropriate and
> potentially misleading. A cursory gl
Jennifer Herbert writes ("[Xen-devel] [PATCH 5/7] libxc: Removing dead code
from xc_dom_allocate()"):
> The only place that jumps to 'err:' does so because !dom, which is
> rechecked in 'err:'. This patch simplifies, giving the same result.
I'm not particularly convinced by this change, but mayb
Jennifer Herbert writes ("[Xen-devel] [PATCH 4/7] libxc: Prevent dereferencing
NULL pointers returned from xc_dom_allocate()"):
> The return from xc_dom_allocate is not checked for a NULL value.
> This patch fixes this, causing it to return from the function with an error.
Acked-by: Ian Jackson
flight 59036 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 589
On 03/07/15 15:16, Ian Campbell wrote:
> On Fri, 2015-06-26 at 19:47 +0200, Julien Grall wrote:
>
>>> +/* First get the #interrupt-cells property of the current cursor
>>> + * that tells us how to interpret the passed-in intspec. If there
>>> + * is none, we are nice and just walk up t
On 30/06/15 14:05, Paul Durrant wrote:
> Use an ioreq_t rather than open coded state, size, dir and data fields
> in struct hvm_vcpu_io. This also allows PIO completion to be handled
> similarly to MMIO completion by re-issuing the handle_pio() call.
>
> Signed-off-by: Paul Durrant
> Cc: Keir Fras
Jennifer Herbert writes ("[Xen-devel] [PATCH 1/7] libxc: fix uninitialized
variable in xc_cpuid_pv_policy()"):
> If xc_domain_get_guest_width were to fail, guest_width is not set, and
> hence guest_64bit becomes undefined.
> Fix is to initialise to 0, and report error if call fails.
...
> diff --g
On 30/06/15 14:05, Paul Durrant wrote:
> Emulation request status is already covered by STATE_IOREQ_XXX values so
> just use those. The mapping is:
>
> HVMIO_none-> STATE_IOREQ_NONE
> HVMIO_awaiting_completion -> STATE_IOREQ_READY
> HVMIO_completed -> STATE_IORESP_READY
>
Jennifer Herbert writes ("[PATCH 0/7] libxc: Fix a number of coverity issues."):
> Fix a number of coverity issues in libxc.
Thanks. Error handling is a pet topic of mine so I will review this
series.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xe
On 30/06/15 14:05, Paul Durrant wrote:
> By removing the HVMIO_dispatched state and making all pending emulations
> (i.e. all those not handled by the hypervisor) use HVMIO_awating_completion,
> various code-paths can be simplified.
>
> The completion case for HVMIO_dispatched can also be trivally
On 30/06/15 14:05, Paul Durrant wrote:
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 2ed0606..efb373f 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -34,11 +34,16 @@ enum hvm_io_state {
> HVMIO_none = 0,
>
On 30/06/15 14:05, Paul Durrant wrote:
> diff --git a/xen/arch/x86/hvm/intercept.c b/xen/arch/x86/hvm/intercept.c
> index 11b6028..f84f7c5 100644
> --- a/xen/arch/x86/hvm/intercept.c
> +++ b/xen/arch/x86/hvm/intercept.c
> @@ -119,8 +119,8 @@ static const struct hvm_io_ops portio_ops = {
> .wri
On 07/01/15 16:49, Konrad Rzeszutek Wilk wrote:
On Sat, Jun 27, 2015 at 07:27:44PM -0400, Don Slutz wrote:
From: Don Slutz
This adds synchronization of the 6 vcpu registers (only 32bits of
them) that vmport.c needs between Xen and QEMU.
...
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x8
On Fri, 2015-07-03 at 12:09 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 1/2] libxl: turn NUMA placement misconfigs
> into warnings"):
> > On Wed, 2015-07-01 at 15:38 +0100, Ian Jackson wrote:
> > > But, be aware that you are making a semantic change to the API which
> > > cannot
On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote:
Anyone fancy (n)acking this followup to XSA-131? I think we probably
want this for 4.6.
> From c395657b03a1e2b7616d987e7078694874981979 Mon Sep 17 00:00:00 2001
> From: Ian Campbell
> Date: Mon, 1 Jun 2015 11:32:23 +0100
> Subject: [PATCH] t
On 03/07/15 15:42, Ian Campbell wrote:
> On Fri, 2015-07-03 at 15:22 +0100, Andrew Cooper wrote:
>> On 03/07/15 15:20, Ian Campbell wrote:
>>> On Wed, 2015-07-01 at 17:37 +, Jennifer Herbert wrote:
Fix a number of coverity issues in libxc.
>>> Do you have CID numbers which should be associ
Ian Campbell writes ("Re: [PATCH v2 1/7] libxl: get rid of the SEDF scheduler"):
> On Fri, 2015-07-03 at 16:33 +0200, Dario Faggioli wrote:
> > I think I'd go for _REMOVED, as deprecated suggests (to me at least)
> > that it's still there but nshould not be used.
>
> REMOVED > DEPRECATED > GONE IM
Ian Campbell writes ("Re: [PATCH v2 1/7] libxl: get rid of the SEDF scheduler"):
> On Fri, 2015-07-03 at 12:24 +0200, Dario Faggioli wrote:
> > @@ -5932,7 +5865,8 @@ int libxl_domain_sched_params_set(libxl_ctx *ctx,
> > uint32_t domid,
...
> > case LIBXL_SCHEDULER_SEDF:
> > -ret=sched
On Fri, 2015-07-03 at 16:36 +0200, Dario Faggioli wrote:
> On Fri, 2015-07-03 at 15:26 +0100, Ian Campbell wrote:
> > On Fri, 2015-07-03 at 12:25 +0200, Dario Faggioli wrote:
> > > -=item B
> > > -=item B
> > > -=item B
> > > -=item B
> >
> > Do these removals imply there are some redundant fields
Ian Campbell writes ("Re: [PATCH OSSTEST v4] mg-all-branch-statuses: Show how
up to date each branch is"):
> On Fri, 2015-07-03 at 14:40 +0100, Ian Jackson wrote:
> > Do you want to provide a cron job to run this weekly, or something ?
>
> Given the "NN days" I was thinking more like daily, other
On Fri, 2015-07-03 at 15:22 +0100, Andrew Cooper wrote:
> On 03/07/15 15:20, Ian Campbell wrote:
> > On Wed, 2015-07-01 at 17:37 +, Jennifer Herbert wrote:
> >> Fix a number of coverity issues in libxc.
> > Do you have CID numbers which should be associated with each of these?
> >
> > See e.g.
On Fri, 2015-07-03 at 15:25 +0100, Andrew Cooper wrote:
> On 01/07/15 12:00, Ian Campbell wrote:
> > On Wed, 2015-07-01 at 11:39 +0100, Andrew Cooper wrote:
> >> On 01/07/15 11:27, Ian Campbell wrote:
> >>> On Wed, 2015-07-01 at 11:16 +0100, Andrew Cooper wrote:
> On 01/07/15 04:07, Yang Hongy
On 01/07/15 18:37, Jennifer Herbert wrote:
> hvm_info->signature is not a string, but an 64 bit int, and is not
> NULL terminated. The use of strncpy to populate it is inappropriate and
> potentially misleading. A cursory glance might have you thinking someone
> had miscounted the length of the s
On 01/07/15 18:37, Jennifer Herbert wrote:
> The only place that jumps to 'err:' does so because !dom, which is
> rechecked in 'err:'. This patch simplifies, giving the same result.
>
> Signed-off-by: Jennifer Herbert
Coverity-ID: 1055188
~Andrew
> ---
> tools/libxc/xc_dom_core.c |7 +
On Fri, 2015-07-03 at 16:33 +0200, Dario Faggioli wrote:
> On Fri, 2015-07-03 at 15:23 +0100, Ian Campbell wrote:
> > On Fri, 2015-07-03 at 12:24 +0200, Dario Faggioli wrote:
> >
> > > @@ -5932,7 +5865,8 @@ int libxl_domain_sched_params_set(libxl_ctx *ctx,
> > > uint32_t domid,
> > >
> > >
On 01/07/15 18:37, Jennifer Herbert wrote:
> If xc_domain_get_guest_width were to fail, guest_width is not set, and
> hence guest_64bit becomes undefined.
> Fix is to initialise to 0, and report error if call fails.
>
> Signed-off-by: Jennifer Herbert
Coverity-ID: 1090350
~Andrew
> ---
> tools
On Tue, 2015-06-30 at 16:00 +0100, Stefano Stabellini wrote:
> When I made this change, I gave a careful look both at the libxl side
> and the QEMU side. Indeed I would appreciate a second pair of eyes on
> this. These are my observations:
I think the request for secondary close review and more im
On Fri, 2015-07-03 at 15:26 +0100, Ian Campbell wrote:
> On Fri, 2015-07-03 at 12:25 +0200, Dario Faggioli wrote:
> > -=item B
> > -=item B
> > -=item B
> > -=item B
>
> Do these removals imply there are some redundant fields in
> libxl_domain_sched_params now?
>
Yes, indeed.
> If so
> shall we
1 - 100 of 241 matches
Mail list logo
