On 19/12/2014 04:58, Wincy Van wrote:
> 2014-12-17 18:46 GMT+08:00 Paolo Bonzini :
>>
>>
>> On 17/12/2014 04:46, Wincy Van wrote:
>>> Hi, all:
>>>
>>> The patchset (https://lkml.org/lkml/2014/3/18/309) fixed migration of
>>> Windows guests, but commit 0bc830b05c667218d703f2026ec866c49df974fc
>>>
On Tue, Dec 09, 2014 at 07:21:40PM +0800, t...@tetrioncapital.com wrote:
> Yes macvtap should be a solution, but somehow libvirt can't turn on VM itself
> afterwards. Any idea?
No, that sounds like a bug because libvirt supports macvtap.
Stefan
pgpoBPBYKr0nV.pgp
Description: PGP signature
Since we decided not to go with KVM due to stability issue, we could let this
go, thanks.
Sent from my BlackBerry 10 smartphone.
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited
Direct: +852-3976-8903
Mobile: +852-9323-9670
Address: 20/F, IFC 1, Central district, Hong Kong
Orig
On 19/12/2014 03:32, Chen, Tiejun wrote:
>
> Are you saying something below?
>
> if (enable_apicv)
> ...
> else {
> kvm_x86_ops->hwapic_irr_update = NULL;
Yes.
> But this means we have to revise hadware_setup() to get 'kvm' inside,
This would not even be possible, since hardware_setu
On 19/12/2014 03:13, Nicholas Krause wrote:
> Remove FIXME comments about needing fault addresses to be returned. These
> are propaagated from walk_addr_generic to gva_to_gpa and from there to
> ops->read_std and ops->write_std.
>
> Signed-off-by: Nicholas Krause
> ---
> arch/x86/kvm/emulate.
On 18/12/2014 19:15, nick wrote:
> /*
>* There is a race window between reading and incrementing, but we do
>* not care about potentially losing timer events in the !reinject
>* case anyway. Note: KVM_REQ_PENDING_TIMER is implicitly checked
>* in vcpu_enter_g
On 19/12/2014 03:19, Wu, Feng wrote:
>>> > >
>>> > > +#ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>>> > > +
>>> > > +struct kvm_irq_routing_table {
>>> > > + int chip[KVM_NR_IRQCHIPS][KVM_IRQCHIP_NUM_PINS];
>>> > > + struct kvm_kernel_irq_routing_entry *rt_entries;
>>> > > + u32 nr_rt_en
On 19/12/2014 06:25, Zhang, Yang Z wrote:
> I see your point. But from performance point, if we can schedule the
> vCPU to another PCPU to handle the interrupt, it would helpful. But I
> remember current KVM will not schedule the vCPU in run queue (even
> though it got preempted) to another pCPU
On 19/12/2014 02:30, Wu, Feng wrote:
>>> How this can work well? All subsequent interrupts are delivered to
>>> one vCPU? It shouldn't be the best solution, need more consideration.
>>
>> Well, it's a hardware limitation. The alternative (which is easy to
>> implement) is to only do PI for singl
On 19/12/2014 02:46, Zhang, Yang Z wrote:
>> If the IRQ is posted, its affinity is controlled by guest (irq <--->
>> vCPU <> pCPU), it has no effect when host changes its affinity.
>
> That's the problem: User is able to changes it in host but it never
> takes effect since it is actually con
On 19/12/2014 15:03, nick wrote:
> Paolo,
> If that is the case why don't I just move this function over if we don't need
> it in this file into x86.c.
> This seems to be the easiest solution from my understanding.
> Regards,
Only that line would have to be moved to x86.c. You can send a patch
On 19/12/2014 15:42, nick wrote:
> Sorry Paolo,
> I am confused of where you would want me to move it as I looked around and
> there seems to be no real place to
> put it.
To a new function called kvm_vcpu_set_pending_timer.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe k
https://bugzilla.kernel.org/show_bug.cgi?id=90081
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 19/12/2014 11:59, t...@tetrioncapital.com wrote:
> Since we decided not to go with KVM due to stability issue, we could let this
> go, thanks.
That's a pity. That said, your decision to not go with KVM due to
stability is a bit strange:
1) unless you are using open source Xen, you are pre
Certain properties of a device are accessible as an array of unsigned
integers, either u64, u32, u16, or u8. Let the VFIO user query this
type of device properties.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/properties.c | 62 +-
1 file changed,
This patch introduced the API to return device properties about
a PLATFORM device (if described by a device tree or ACPI) and the
skeleton of the implementation for VFIO_PLATFORM. Information about any
device node bound by VFIO_PLATFORM should be queried via the introduced
ioctl VFIO_DEVICE_GET_DEV
Certain device properties (e.g. the device node name, the compatible
string), are available as a list of strings (separated by the null
terminating character). Let the VFIO user query this type of properties.
Signed-off-by: Antonios Motakis
---
drivers/vfio/platform/properties.c | 43 +++
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, December 19, 2014 8:01 PM
> To: Zhang, Yang Z; Wu, Feng; Paolo Bonzini; KVM list
> Cc: io...@lists.linux-foundation.org; linux-ker...@vger.kernel.org
> Subject: Re: [v3
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, December 19, 2014 8:00 PM
> To: Wu, Feng; linux-ker...@vger.kernel.org
> Cc: io...@lists.linux-foundation.org; kvm@vger.kernel.org
> Subject: Re: [v3 16/26] KVM: Make s
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, December 19, 2014 7:59 PM
> To: Wu, Feng; Paolo Bonzini; Zhang, Yang Z; Thomas Gleixner; Ingo Molnar; H.
> Peter Anvin; x...@kernel.org; Gleb Natapov; dw...@infradead.o
20 matches
Mail list logo
