to confuse a lot more
> users than it would clarify.
I'll bring you a nice bottle of scotch at the next KVM Forum if you can
find me one user that can accurately describe what steal time is.
The semantics are so incredibly subtle that I have a hard time believing
anyone actually understand
due to overcommit (with the reminder being unallocated
> time). The guest could then present it any way it wanted to.
What I had previously suggested what splitting entitlement loss out of
steal time and reporting it as a separate metric (but not reporting a
fixed notion of entitlement).
You'
;t matter when it doesn't agree
with all of the existing implementations.
Users use implementations, not specifications. The specification really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
proposing.
In this case, we should simply say that with the feature bit, the vnet
header can be in the same element as the data but not allow the header
to be spread across multiple elements.
Regards,
Anthony Liguori
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kc
Rusty Russell writes:
> Anthony Liguori writes:
>> Rusty Russell writes:
>>
>>> "Michael S. Tsirkin" writes:
>>>
>>>> Thinking about Sasha's patches, we can reduce ring usage
>>>> for virtio net small packets dramatically
This maps really nicely to non-PCI transports too. But extending the
PCI config space (especially dealing with capability allocation) is
pretty gnarly and there isn't an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device
If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
a "panic-device" should cover other OSes is also
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic?
>
> Is the mechanism general enough for supporting new events, etc.
Hi,
I
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >>
>> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wro
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti writes:
>> >>
>> >>
ional. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
i
y likely to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To
"Michael S. Tsirkin" writes:
> On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
>> Of course, the million dollar question is why would using AIO in the
>> kernel be faster than using AIO in userspace?
>
> Actually for me a more important questio
o drivers/watchdog/, and gain a more complete solution to
> detecting hangs inside the guest.
The purpose of virtio is not to reinvent every possible type of device.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
king port 0x0505 is safe for something like this (as long as
you check to make sure that you really are under KVM).
Regards,
Anthony Liguori
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More ma
Sasha Levin writes:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>> +#define KVM_PV_PORT (0x505UL)
>>>> +
>>>> #ifdef __KERNEL__
>>
Sasha Levin writes:
> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>>> Sasha Levin writes:
>>>
>>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>>> +#define KVM_PV_PORT (0x5
Sasha Levin writes:
> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>>> We can know the guest is panicked when the guest runs on xen.
>>>> But we do not have such f
ding on what
feature bits are exposed to the guest. So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ad64/pwrite64).
That all happened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
be compatible than wouldn't xen-24.0 be compatible
too? I think the point was that you should either be checking for
'xen-3.x' or something more general that would accept anything >= xen-3.0.
Regards,
Anthony Liguori
But this is just a sanity check to make sure things are basic
,
Anthony Liguori
Ryo Tsuruta wrote:
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-map
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static void vp_notify(struct virtqueue *vq
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
Avi Kivity wrote:
Anthony Liguori wrote:
Well please propose the virtio API first and then I'll adjust the PCI
ABI. I don't want to build things into the ABI that we never
actually end up using in virtio :-)
Move ->kick() to virtio_driver.
Then on each kick, all queu
mber of devices on a
PCI bus? My concern was that it was limited by something stupid like an
8-bit identifier.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Anthony Liguori wrote:
Joerg Roedel wrote:
The generic x86 code has to know if the specific implementation uses
Nested
Paging. In the generic code Nested Paging is called Hardware Assisted
Paging
(HAP) to avoid confusion with (future) HAP implementations of other
vendors.
This patch exports
ol npt_enabled = false;
+static char *npt = "on";
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do
nasty things like implicitly cast a literal to a char *.
Regards,
Anthony Liguori
static void kvm_reput_irq(struc
obably return false here until the
patch that actually implements NPT support. Otherwise, the 7th patch in
this series breaks KVM for SVM.
Regards,
Anthony Liguori
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -
start
running the install CDs for 32-bit and 64-bit Ubuntu, 32-bit OpenSuSE,
64-bit Fedora, and 32-bit Win2k8. I'll do a more thorough run of
kvm-test on Monday when I have a better connection to my machine.
Nice work!
Regards,
Anthony Liguori
Joerg
Here is the diffstat:
arch/x8
o disagree. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
2. A lot of people would like to view (and Demo) it side-by-side.
3. Useful for BETA
Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been ab
ake kvm_para.h #include-able from userspace.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE
A very simple paravirt_ops implementation for KVM. Future patches will add
more sophisticated optimizations. The goal of having this presenting this now
is to validate the new hypercall infrastructure and to make my patch queue
smaller.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
On Wed, 2007-08-29 at 04:12 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > This patch refactors the current hypercall infrastructure to better support
> > live
> > migration and SMP. It eliminates the hypercall page by trapping
On Wed, 2007-08-29 at 04:31 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > @@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
> > }
> > sort_main_extable();
> > trap_init();
> > + k
I think that it would be nicer to implement the p9 transport on top of
virtio instead of directly on top of PCI. I think your PCI transport
would make a pretty nice start of a PCI virtio transport though.
Regards,
Anthony Liguori
On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote
seem to be virtualizing the virtio vendor/device IDs
(which is what I'm currently doing) or to mandate that the virtio vendor
ID be within the PCI vendor ID space. It's probably not necessary to
make the same requirement for device IDs though.
What are your thoughts?
Regards,
Anthony Ligu
7;ll start submitting
patches.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Anthony Liguori wrote:
Hi Rusty,
I've written a PCI virtio transport and noticed something strange.
All current in-tree virtio devices register ID tables that match a
specific device ID, but any vendor ID.
This is incompatible with using PCI vendor/device IDs for virtio
vendor/devic
Rusty Russell wrote:
On Wednesday 07 November 2007 04:48:35 Anthony Liguori wrote:
Semantically, find requires that a field have both a type and a length.
With the exception of the VIRTQUEUE field used internally by lguest,
type is always a unique identifier. Since virtqueue information is not
bug is exposed.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index ac69e7b..5b88d21 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -92,8 +92,8 @@ static inline void vring_init(struct
ensure that we had a clean PCI ABI that would
be natural to implement on a platform like Windows. I think with the
recent config_ops refactoring, we can now do that.
Regards,
Anthony Liguori
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
entiate based on the subsystem IDs.
Regards,
Anthony Liguori
We will support non-pci for s390, but in order to support Windows and
older Linux PCI is necessary.
The aim is that PCI support is clean, but that we're not really tied to PCI.
I think we're getting closer wit
s since it's trivial to handle for both the PCI backend and the
lguest backend (lguest doesn't need to do any endianness conversion).
Regards,
Anthony Liguori
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
diff --git a/include/linux/virtio_net.h b/include/linux/virtio
g last_used_idx to the correct type.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e4baca..0e1bf05 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -53,7 +53,7 @@ struct vring_vi
This patch moves virtio under the virtualization menu and changes virtio
devices to not claim to only be for lguest.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/Kconfig b/drivers/Kconfig
index f4076d9..d945ffc 100644
--- a/drivers/Kconfig
+++ b/drivers/K
This is needed for the virtio PCI device to be compiled as a module.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e1bf05..3f28b47 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_
This patch series implements a PCI driver for virtio. This allows virtio
devices (like block and network) to be used in QEMU/KVM. I'll post a very
early KVM userspace backend in kvm-devel for those that are interested.
This series depends on the two virtio fixes I've posted and Rusty's config_op
Rusty Russell wrote:
On Wednesday 07 November 2007 13:52:29 Anthony Liguori wrote:
This patch fixes a typo in vring_init().
Thanks, applied.
I've put it in the new, experimental virtio git tree on git.kernel.org.
Hrm, perhaps you forgot to push? I don't see it i
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->get() ops to ioreadXX depending on the
size which already does the endianness conversion for me so t
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 9e33fc4..c81e0f3 100644
--- a/drivers/
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in virtio_
evice showed up like a normal PCI device.
Am I misunderstanding what you're asking about?
Regards,
Anthony Liguori
I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fuss.
What is the use case you're thinking of? A semi-paravi
twice in the system, once via emulated ide, once as pv disk.
Ouch.
I have actually addressed this problem with a PV option rom for QEMU. I
expect to get time to submit the QEMU patches by the end of the year.
See http://hg.codemonkey.ws/extboot
Regards,
Anthony Liguori
-
To unsub
transport uses hypercalls and shared memory.
Regards,
Anthony Liguori
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Arnd Bergmann wrote:
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->g
Dor Laor wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a pr
ou have to have an instruction decoder which
is goes against the earlier goal ;-)
Regards,
Anthony Liguori
I don't know about problems in other architectures, maybe mmio is better?
Dor.
Apologies in advance for my failure to pay attention.
thanks
ron
___
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev->max_seg & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev->max_seg >> 8) & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG
I have my doubts that a
paravirt disk driver will significantly out perform scsi emulation.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
. attached patch is just to illustrate the point. Has not even been
compile tested.
Regards,
Anthony Liguori
--- linux-2.6.21-rc1/arch/i386/kernel/vmi.c~ 2007-02-20 22:32:30.0 -0600
+++ linux-2.6.21-rc1/arch/i386/kernel/vmi.c 2007-02-26 17:58:18.0 -0600
@@ -852,9 +852,9 @@
#endif
Zachary Amsden wrote:
Anthony Liguori wrote:
Hi Zach,
It seems to me that the APIC paravirt_ops should be filled by
para_fill() instead of vmi_get_function(). vmi_get_function()
returns a nop when the relocation type is NONE. para_fill() leaves
the native code in place.
The native
Zachary Amsden wrote:
Anthony Liguori wrote:
Hi Zach,
It seems to me that the APIC paravirt_ops should be filled by
para_fill() instead of vmi_get_function(). vmi_get_function()
returns a nop when the relocation type is NONE. para_fill() leaves
the native code in place.
The native
en a PIO operation would be a bit cleaner IMHO. PIO exits
tend to be fast in VT/SVM so that's an added benefit.
Regards,
Anthony Liguori
Ingo Molnar wrote:
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardwar
ne to work around it.
Sorry. Contact Lenovo and ask for a BIOS update.
Regards,
Anthony Liguori
/proc/cpuinfo shows "VMX".
Another question ... how to enable "mouse" in KVM?
Thanks,
Jeff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
efore.
The odd thing is that it's probing some space that is marked reserved in
the LSI manual. Unfortunately, I couldn't understand the SCSI system
well enough to understand what changed in Linux.
Regards,
Anthony Liguori
I tried "git bisect" and found out there's
ually very conservative seeing as how disabling CR4.PGE
should be sufficient to flush global pages on modern processors. I
suspect you're getting preempted while it's running.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
way to go. There simply
isn't a significant performance overhead to copying the relatively small
amount of memory.
So virtio in it's current form would actually be pretty useful for that.
Regards,
Anthony Liguori
cheers,
Gerd
-
To unsubscribe from this list: send the line &quo
a2 = vcpu->regs[VCPU_REGS_RDX] & -1u;
a3 = vcpu->regs[VCPU_REGS_RSI] & -1u;
Anthony? I think you were hacking this area?
I make a similar change in my series.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "
'm planning on breaking this interface again since the new hypercall
API only takes 4 arguments instead of 6.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
?
Regards,
Anthony Liguori
I cannot provide any more information for now causes system freezes at all and
netconsole not works with ipw3945 (netconsole: eth1 doesn't support polling,
aborting) but tomorrow i'll try with cable.
If needed you can find .config and dmesg from [1], if
Jeff Dike wrote:
On Tue, Jul 17, 2007 at 09:15:51AM -0500, Anthony Liguori wrote:
I'm planning on breaking this interface again since the new hypercall
API only takes 4 arguments instead of 6.
Is anything written anywhere about this hypercall interface?
I've posted patc
Jeff Dike wrote:
On Wed, Jul 18, 2007 at 11:28:18AM -0500, Anthony Liguori wrote:
Within the kernel right (VMCALL is only usable in ring 1).
Yup.
Is it
terribly important to be able to pass through the syscall arguments in
registers verses packing them in a data structure and
is: do you still plan to switch to a syscall
interface?
What benefit would a syscall interface have?
Regards,
Anthony Liguori
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay
about.
Fine, so lets move kvm paravirtualitzation into vmi too (proof of
concept code by Anthony Liguori exists) and kill one more item on the
(linux) QA test matrix? (just following your arguments, not that I'm
confident it would actually help reducing QA effort).
yes - although obviou
Nakajima, Jun wrote:
Anthony Liguori wrote:
Ingo Molnar wrote:
* Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
So in the end you would still have two different hypervisor ABI's,
the VMI ROM just hides that.
oh, but that way i have cleverly pushed the pro
lot of things that HVM does not need.
Since KVM and Xen HVM have the least requirements in term of guest
modifications, they are probably the obviously places to start.
Regards,
Anthony Liguori
It
would at least give us a better idea of the scope of the problem. But
IMHO it's a *hug
ms.
Furthermore, in the future, I strongly suspect that HVM will become much
more important for Xen than PV and since that already has a PCI bus it's
not really that big of a deal.
Regards,
Anthony Liguori
J
-
To unsubscribe from this list: send the line "unsubscribe linux-
hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drive
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
The whole point of using the instruction is to allow hypercalls to be
used in many locations. This has the nice side effect of not
requiring a central hypercall initialization routine in the guest to
fetch the hypercall page. A PV driver
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Yeah, see, the initial goal was to make it possible to use the KVM
paravirtualizations on other hypervisors. However, I don't think this
is really going to be possible in general so maybe it's better to just
use leaf 0. I
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
So then each module creates a hypercall page using this magic MSR and
the hypervisor has to keep track of it so that it can appropriately
change the page on migration. The page can only contain a single
ned-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#de
without
user interaction.
There's no tangible benefit to us to use 0x4000. Therefore I'm
inclined to lean toward making things easier for others.
Regards,
Anthony Liguori
And like CPUID.1, CPUID.0x4001 returns the version number in
eax, and each VMM should be able to define
toward just using . If for no other reason
than the hypercall space is unsharable.
Regards,
Anthony Liguori
Likewise if KVM paravirtualization interface (as kind of "open source
paravirtualization interface") is detected in the generic areas (not in
vender-specific), any guest can
0 1000 and using the MSR
trickery that you propose.
As long as we all agree not to use 4000 1000 for now, it leaves open the
possibility of having a generic interface in the future.
Regards,
Anthony Liguori
J
-
hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drive
Avi Kivity wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better
support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the
along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+
+/*
+ * No need for any &
MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#
Since a hypercall may span two pages and is a gva, we need a function to write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been ab
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > Since a hypercall may span two pages and is a gva, we need a function to
> > write
> > to a gva that may span multiple pages. emulator_write_phys() seems like the
> > logical choice
On Mon, 2007-08-27 at 19:06 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > {
> > int i;
> > @@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > vcpu->regs[VCPU_REGS_RBX] =
1 - 100 of 109 matches
Mail list logo
