Re: [PATCH v8 2/4] block: add the command line support
On Fri, Sep 23, 2011 at 11:54 PM, Kevin Wolf wrote:
> Am 08.09.2011 12:11, schrieb Zhi Yong Wu:
>> Signed-off-by: Zhi Yong Wu
>> ---
>> block.c | 59
>> +++
>> block.h | 5
>> block_int.h | 3 ++
>> blockdev.c | 29 +++
>> qemu-config.c | 24 ++
>> qemu-options.hx | 1 +
>> 6 files changed, 121 insertions(+), 0 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index 43742b7..cd75183 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -104,6 +104,57 @@ int is_windows_drive(const char *filename)
>> }
>> #endif
>>
>> +/* throttling disk I/O limits */
>> +void bdrv_io_limits_disable(BlockDriverState *bs)
>> +{
>> + bs->io_limits_enabled = false;
>> +
>> + if (bs->block_queue) {
>> + qemu_block_queue_flush(bs->block_queue);
>> + qemu_del_block_queue(bs->block_queue);
>> + bs->block_queue = NULL;
>> + }
>> +
>> + if (bs->block_timer) {
>> + qemu_del_timer(bs->block_timer);
>> + qemu_free_timer(bs->block_timer);
>> + bs->block_timer = NULL;
>> + }
>> +
>> + bs->slice_start = 0;
>> +
>> + bs->slice_end = 0;
>
> Remove the empty line between slice_start and slice_end?
Yeah, thanks.
>
>> +}
>> +
>> +static void bdrv_block_timer(void *opaque)
>> +{
>> + BlockDriverState *bs = opaque;
>> + BlockQueue *queue = bs->block_queue;
>> +
>> + qemu_block_queue_flush(queue);
>
> Hm, didn't really notice it while reading patch 1, but
> qemu_block_queue_flush() is misleading. It's really something like
Why do you say this is misleading?
> qemu_block_queue_submit().
Right. It will resubmit all enqueued I/O requests.
>
>> +}
>> +
>> +void bdrv_io_limits_enable(BlockDriverState *bs)
>> +{
>> + bs->block_queue = qemu_new_block_queue();
>> + bs->block_timer = qemu_new_timer_ns(vm_clock, bdrv_block_timer, bs);
>> +
>> + bs->slice_start = qemu_get_clock_ns(vm_clock);
>> +
>> + bs->slice_end = bs->slice_start + BLOCK_IO_SLICE_TIME;
>> +}
>
> Same as above.
got it. I will remove, thanks.
>
>> +
>> +bool bdrv_io_limits_enabled(BlockDriverState *bs)
>> +{
>> + BlockIOLimit *io_limits = &bs->io_limits;
>> + return io_limits->bps[BLOCK_IO_LIMIT_READ]
>> + || io_limits->bps[BLOCK_IO_LIMIT_WRITE]
>> + || io_limits->bps[BLOCK_IO_LIMIT_TOTAL]
>> + || io_limits->iops[BLOCK_IO_LIMIT_READ]
>> + || io_limits->iops[BLOCK_IO_LIMIT_WRITE]
>> + || io_limits->iops[BLOCK_IO_LIMIT_TOTAL];
>> +}
>> +
>> /* check if the path starts with ":" */
>> static int path_has_protocol(const char *path)
>> {
>> @@ -1453,6 +1504,14 @@ void bdrv_get_geometry_hint(BlockDriverState *bs,
>> *psecs = bs->secs;
>> }
>>
>> +/* throttling disk io limits */
>> +void bdrv_set_io_limits(BlockDriverState *bs,
>> + BlockIOLimit *io_limits)
>> +{
>> + bs->io_limits = *io_limits;
>> + bs->io_limits_enabled = bdrv_io_limits_enabled(bs);
>> +}
>> +
>> /* Recognize floppy formats */
>> typedef struct FDFormat {
>> FDriveType drive;
>> diff --git a/block.h b/block.h
>> index 3ac0b94..a3e69db 100644
>> --- a/block.h
>> +++ b/block.h
>> @@ -58,6 +58,11 @@ void bdrv_info(Monitor *mon, QObject **ret_data);
>> void bdrv_stats_print(Monitor *mon, const QObject *data);
>> void bdrv_info_stats(Monitor *mon, QObject **ret_data);
>>
>> +/* disk I/O throttling */
>> +void bdrv_io_limits_enable(BlockDriverState *bs);
>> +void bdrv_io_limits_disable(BlockDriverState *bs);
>> +bool bdrv_io_limits_enabled(BlockDriverState *bs);
>> +
>> void bdrv_init(void);
>> void bdrv_init_with_whitelist(void);
>> BlockDriver *bdrv_find_protocol(const char *filename);
>> diff --git a/block_int.h b/block_int.h
>> index 201e635..368c776 100644
>> --- a/block_int.h
>> +++ b/block_int.h
>> @@ -257,6 +257,9 @@ void qemu_aio_release(void *p);
>>
>> void *qemu_blockalign(BlockDriverState *bs, size_t size);
>>
>> +void bdrv_set_io_limits(BlockDriverState *bs,
>> + BlockIOLimit *io_limits);
>> +
>> #ifdef _WIN32
>> int is_windows_drive(const char *filename);
>> #endif
>> diff --git a/blockdev.c b/blockdev.c
>> index 2602591..619ae9f 100644
>> --- a/blockdev.c
>> +++ b/blockdev.c
>> @@ -236,6 +236,7 @@ DriveInfo *drive_init(QemuOpts *opts, int
>> default_to_scsi)
>> int on_read_error, on_write_error;
>> const char *devaddr;
>> DriveInfo *dinfo;
>> + BlockIOLimit io_limits;
>> int snapshot = 0;
>> int ret;
>>
>> @@ -354,6 +355,31 @@ DriveInfo *drive_init(QemuOpts *opts, int
>> default_to_scsi)
>> }
>> }
>>
>> + /* disk I/O throttling */
>> + io_limits.bps[BLOCK_IO_LIMIT_TOTAL] =
>> + qemu_opt_get_number(opts, "bps", 0);
>> + io_limits.bps[BLOCK_IO_LIMIT_READ] =
>> + qemu_opt_get_number(opts, "bps_rd", 0);
>> + io_limits.bps[BLOCK_IO_LIMIT_WRITE] =
>> +
Re: [PATCH v2] kvm tools: Support multiple net devices
On Sun, Sep 25, 2011 at 2:11 PM, Sasha Levin wrote: > This patch adds support for multiple network devices. The command line syntax > changes to the following: > > --network/-n [mode=[tap/user/none]] [guest_ip=[guest ip]] [host_ip= > [host_ip]] [guest_mac=[guest_mac]] [script=[script]] > > Each of the parameters is optional, and the config defaults to a TAP based > networking with a sequential MAC. > > Signed-off-by: Sasha Levin Seems reasonable. Asias, is v2 OK to merge? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about duplicate memory work
On 9/25/11, Robin Lee Powell wrote: > > OK, so I've got a Linux host, and a bunch of Linux VMs. > > This means that the host *and* all tho VMs do their own disk > caches/buffers and do their own swap as well. If I'm not wrong, that's why the recommended and current default in libvirtd is to create storage devices with no caching to remove one layer of duplication. > I've considered turning off swap on the VMs so all the swapping at > least happens in *one place*; I dunno if that's best. Not sure it's a good idea. If the VM needs more working memory than you allocated, I think it locks up dead if there is insufficient swap space. At least that appears to be what happened to one of mine. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] acpi: fix up EJ0 in DSDT
On Thu, Sep 22, 2011 at 09:09:49AM +0300, Michael S. Tsirkin wrote: > On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote: > > The code to generate basic SSDT code isn't that difficult (see > > build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to > > patch the DSDT versus just generating the necessary blocks in an SSDT? > > I don't really care whether the code is in DSDT or SSDT, > IMO there isn't much difference between build_ssdt and patching: > main reason is build_ssdt uses offsets hardcoded to a specific binary > (ssdt_proc and SD_OFFSET_* ) while I used > a script to extract offsets. Yes - your script to extract the offsets is nice. > I think we should avoid relying on copy-pasted binary > because I see the related ASL code changing in the near future > (with multifunction and bridge support among others). Can you expand on this? Would multi-function and bridge support make patching easier than dynamic SSDT generation? I'm a little leary of patching the DSDT - doubly so when the DSDT is creating dummy devices that are then dynamically patched out. (For example, even with your patch series there are still two devices defined with _ADR 1.) It seems more straight-forward to just create the devices that are needed. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCHv2] tools: kvm: don't use custom strtoul for hex numbers
On Fri, Sep 23, 2011 at 5:53 PM, Andy Shevchenko wrote: > Signed-off-by: Andy Shevchenko > Cc: Pekka Enberg > Cc: kvm@vger.kernel.org > Signed-off-by: Andy Shevchenko Applied, thanks! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: Fix inject-nmi
On 2011-09-25 16:07, Avi Kivity wrote: > On 09/23/2011 12:31 PM, Lai Jiangshan wrote: >> > Moreover: wrong indention. >> > >> > You know that this won't work for qemu-kvm with in-kernel irqchip? You >> > may want to provide a patch for that tree, emulating the unavailable >> > LINT1 injection via testing the APIC configration and then raising an >> > NMI as before if it is accepted. >> > >> >> It works in my box but the NMI is not injected through the in-kernel >> irqchip, >> I will implement it as you suggested. > > Somewhat hacky; isn't it better to test LINT1 in the kernel (and > redefine the KVM_NMI ioctl as "toggle LINT1")? KVM_NMI is required for user space IRQ chip as well. Introducing some KVM_SET_LINT1 is an option though. But emulating it for the NMI button on older kernels sounds worthwhile nevertheless. Jan signature.asc Description: OpenPGP digital signature
RE: [PATCH] KVM: emulate lapic tsc deadline timer for guest
Marcelo Tosatti wrote: > On Fri, Sep 23, 2011 at 04:25:51PM +0800, Liu, Jinsong wrote: >> Marcelo Tosatti wrote: >>> On Thu, Sep 22, 2011 at 04:55:52PM +0800, Liu, Jinsong wrote: > From 4d5b83aba40ce0d421add9a41a6c591a8590a32e Mon Sep 17 00:00:00 > 2001 From: Liu, Jinsong Date: Thu, 22 Sep 2011 14:00:08 +0800 Subject: [PATCH 2/2] KVM: emulate lapic tsc deadline timer for guest This patch emulate lapic tsc deadline timer for guest: Enumerate tsc deadline timer capability by CPUID; Enable tsc deadline timer mode by lapic MMIO; Start tsc deadline timer by WRMSR; Signed-off-by: Liu, Jinsong --- arch/x86/include/asm/kvm_host.h |2 + arch/x86/kvm/kvm_timer.h|2 + arch/x86/kvm/lapic.c| 123 --- arch/x86/kvm/lapic.h |3 + arch/x86/kvm/x86.c | 16 +- 5 files changed, 123 insertions(+), 23 deletions(-) >>> >>> Looks good, please rebase against branch master of >>> >>> git://github.com/avikivity/kvm.git >> >> Rebased as attached. >> >> Thanks, >> Jinsong > > Please write a simple test case to arm a lapic timer via wrmsr (see > https://github.com/avikivity/kvm-unit-tests). > > Kernel patches have been applied, thanks. Marcelo, I'm not quite clear the purpose and usage of test case of the kvm-unit-tests. Can you give me some hint? Thanks, Jinsong-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Biweekly KVM Test report, kernel 1e0e12af... qemu ad305c9f...
Hi All, This is KVM test result against kvm.git 1e0e12af7606a7d4063654eb294c8fd554c71a25 based on kernel 3.1.0-rc5+, and qemu.git ad305c9fc6f2c037f47b3274ceace4ebc81160ed. We found 2 new bugs during the past two weeks. Both of them are qemu bugs. One of them is that guest boot up too slowly. The other is that 64-bit windows guest cannot boot up. We found no bugs got fixed. New issues: 1. guest boots up too slowly https://bugs.launchpad.net/qemu/+bug/855633 2. 64-bit windows guest cannot boot up https://bugs.launchpad.net/qemu/+bug/855664 Fixed issue: Old issues(5): -- 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detail&aid=2723366&group_id=180599&atid=893831 2. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detail&aid=2721640&group_id=180599&atid=893831 3. [vt-d] NIC assignment order in command line make some NIC can't work https://bugs.launchpad.net/qemu/+bug/7990367 4. I/O errors after "Save/Restore" https://bugs.launchpad.net/qemu/+bug/739088 5. VF doesn't work in guest when not pinned with "addr=" https://bugs.launchpad.net/qemu/+bug/830558 Test environment: == Platform Westmere-EP SanyBridge-EP CPU Cores 24 32 Memory size 10G 32G Report summary of IA32E on Westmere-EP: Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel_ept_vpid 12 4 7 10 control_panel_ept 4 2 2 00 control_panel_vpid 3 2 1 00 control_panel 3 2 1 00 gtest_vpid 1 0 1 00 gtest_ept 1 0 1 00 gtest 3 1 2 00 vtd_ept_vpid3 0 3 00 gtest_ept_vpid 12 2 1000 sriov_ept_vpid 6 0 6 00 = control_panel_ept_vpid 12 4 7 10 :KVM_LM_Continuity_64_g3 1 0 1 00 :KVM_four_dguest_64_g32e 1 0 1 00 :KVM_SR_SMP_64_g32e1 0 1 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_two_winxp_64_g32e 1 0 1 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 0 10 :KVM_256M_guest_64_g32e1 1 0 00 :KVM_four_sguest_64_g32e 1 0 1 00 control_panel_ept 4 2 2 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 control_panel_vpid 3 2 1 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 control_panel 3 2 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 gtest_vpid 1 0 1 00 :boot_smp_win7_ent_64_g3 1 0 1 00 gtest_ept 1 0 1 00 :boot_smp_win7_ent_64_g3 1 0 1 00 gtest 3 1 2 00 :boot_smp_win2008_64_g32 1 0 1 00 :boot_smp_win7_ent_64_gP 1 1 0 00 :boot_smp_vista_64_g32e1 0 1 00 vtd_ept_vpid3 0 3 00 :one_pcie_smp_xp_64_g32e 1 0 1 00 :one_pcie_smp_64_g32e 1 0 1 00 :two_dev_smp_64_g32e 1 0 1 00 gtest_ept_vpid
Re: [Qemu-devel] [PATCH] qemu: Fix inject-nmi
On 09/23/2011 12:31 PM, Lai Jiangshan wrote: > Moreover: wrong indention. > > You know that this won't work for qemu-kvm with in-kernel irqchip? You > may want to provide a patch for that tree, emulating the unavailable > LINT1 injection via testing the APIC configration and then raising an > NMI as before if it is accepted. > It works in my box but the NMI is not injected through the in-kernel irqchip, I will implement it as you suggested. Somewhat hacky; isn't it better to test LINT1 in the kernel (and redefine the KVM_NMI ioctl as "toggle LINT1")? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Biweekly KVM Test report, kernel 1e0e12af... qemu ad305c9f...
Hi All, This is KVM test result against kvm.git 1e0e12af7606a7d4063654eb294c8fd554c71a25 based on kernel 3.1.0-rc5+, and qemu.git ad305c9fc6f2c037f47b3274ceace4ebc81160ed. We found 2 new bugs during the past two weeks. Both of them are qemu bugs. One of them is that guest boot up too slowly. The other is that 64-bit windows guest cannot boot up. We found no bugs got fixed. New issues: 1. guest boots up too slowly https://bugs.launchpad.net/qemu/+bug/855633 2. 64-bit windows guest cannot boot up https://bugs.launchpad.net/qemu/+bug/855664 Fixed issue: Old Issues list: bugs(6) -- 1. NIC & USB Failures in KVM-86 w/VT-d http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=193 2. [VT-d] Sata disk cannot be assign to guest http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=209 3. [VT-d] NHM-EX system print "NMI received for unknown reason" continuously when shutdown vtd guest http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=214 4. KVM guest cannot load Myricom driver successfully http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=234 5. [KVM-User] guest doesn't support more than 8 assigned devices http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=258 6. [VT-d] NIC assignment order in command line makes some NIC can't work http://otc-qa.sh.intel.com/kvm/bugzilla/show_bug.cgi?id=260 7. I/O errors after "Save/Restore" https://bugs.launchpad.net/qemu/+bug/739088 8. VF doesn't work in guest when not pinned with "addr=" https://bugs.launchpad.net/qemu/+bug/830558 Test environment: == Platform Westmere-EP SanyBridge-EP CPU Cores 24 32 Memory size 10G 32G Report summary of IA32E on Westmere-EP: Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel_ept_vpid 12 4 7 10 control_panel_ept 4 2 2 00 control_panel_vpid 3 2 1 00 control_panel 3 2 1 00 gtest_vpid 1 0 1 00 gtest_ept 1 0 1 00 gtest 3 1 2 00 vtd_ept_vpid3 0 3 00 gtest_ept_vpid 12 2 1000 sriov_ept_vpid 6 0 6 00 = control_panel_ept_vpid 12 4 7 10 :KVM_LM_Continuity_64_g3 1 0 1 00 :KVM_four_dguest_64_g32e 1 0 1 00 :KVM_SR_SMP_64_g32e1 0 1 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_two_winxp_64_g32e 1 0 1 00 :KVM_256M_guest_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 0 10 :KVM_256M_guest_64_g32e1 1 0 00 :KVM_four_sguest_64_g32e 1 0 1 00 control_panel_ept 4 2 2 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 control_panel_vpid 3 2 1 00 :KVM_linux_win_64_g32e 1 0 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 control_panel 3 2 1 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_LM_SMP_64_g32e1 0 1 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 gtest_vpid 1 0 1 00 :boot_smp_win7_ent_64_g3 1 0 1 00 gtest_ept 1 0 1 00 :boot_smp_win7_ent_64_g3 1 0 1 00 gtest 3 1 2 00 :boot_smp_win2008_64_g32 1 0 1 00 :boot_smp_win7_ent_64_gP 1 1 0
[PATCH v2] kvm tools: Support multiple net devices
This patch adds support for multiple network devices. The command line syntax
changes to the following:
--network/-n [mode=[tap/user/none]] [guest_ip=[guest ip]] [host_ip=
[host_ip]] [guest_mac=[guest_mac]] [script=[script]]
Each of the parameters is optional, and the config defaults to a TAP based
networking with a sequential MAC.
Signed-off-by: Sasha Levin
---
tools/kvm/builtin-run.c | 146
tools/kvm/virtio/net.c | 155 +-
2 files changed, 191 insertions(+), 110 deletions(-)
diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-run.c
index 28dc95a..070b1b6 100644
--- a/tools/kvm/builtin-run.c
+++ b/tools/kvm/builtin-run.c
@@ -87,9 +87,12 @@ static bool sdl;
static bool balloon;
static bool using_rootfs;
static bool custom_rootfs;
+static bool no_net;
extern bool ioport_debug;
extern int active_console;
extern int debug_iodelay;
+struct virtio_net_parameters *net_params;
+int num_net_devices;
bool do_debug_print = false;
@@ -182,6 +185,89 @@ static int tty_parser(const struct option *opt, const char
*arg, int unset)
return 0;
}
+static inline void str_to_mac(const char *str, char *mac)
+{
+ sscanf(str, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
+ mac, mac+1, mac+2, mac+3, mac+4, mac+5);
+}
+static int set_net_param(struct virtio_net_parameters *p, const char *param,
+ const char *val)
+{
+ if (strcmp(param, "guest_mac") == 0) {
+ str_to_mac(val, p->guest_mac);
+ } else if (strcmp(param, "mode") == 0) {
+ if (!strncmp(val, "user", 4)) {
+ int i;
+
+ for (i = 0; i < num_net_devices; i++)
+ if (net_params[i].mode == NET_MODE_USER)
+ die("Only one usermode network device
allowed at a time");
+ p->mode = NET_MODE_USER;
+ } else if (!strncmp(val, "tap", 3)) {
+ p->mode = NET_MODE_TAP;
+ } else if (!strncmp(val, "none", 4)) {
+ no_net = 1;
+ return -1;
+ } else
+ die("Unkown network mode %s, please use user, tap or
none", network);
+ } else if (strcmp(param, "script") == 0) {
+ p->script = val;
+ } else if (strcmp(param, "guest_ip") == 0) {
+ p->guest_ip = val;
+ } else if (strcmp(param, "host_ip") == 0) {
+ p->host_ip = val;
+ }
+
+ return 0;
+}
+
+static int netdev_parser(const struct option *opt, const char *arg, int unset)
+{
+ struct virtio_net_parameters p;
+ char *buf, *cmd = NULL, *cur = NULL;
+ bool on_cmd = true;
+
+ if (arg) {
+ buf = strdup(arg);
+ if (buf == NULL)
+ die("Failed allocating new net buffer");
+ cur = strtok(buf, ",=");
+ }
+
+ p = (struct virtio_net_parameters) {
+ .guest_ip = DEFAULT_GUEST_ADDR,
+ .host_ip= DEFAULT_HOST_ADDR,
+ .script = DEFAULT_SCRIPT,
+ .mode = NET_MODE_TAP,
+ };
+
+ str_to_mac(DEFAULT_GUEST_MAC, p.guest_mac);
+ p.guest_mac[5] += num_net_devices;
+
+ while (cur) {
+ if (on_cmd) {
+ cmd = cur;
+ } else {
+ if (set_net_param(&p, cmd, cur) < 0)
+ goto done;
+ }
+ on_cmd = !on_cmd;
+
+ cur = strtok(NULL, ",=");
+ };
+
+ num_net_devices++;
+
+ net_params = realloc(net_params, num_net_devices * sizeof(*net_params));
+ if (net_params == NULL)
+ die("Failed adding new network device");
+
+ net_params[num_net_devices - 1] = p;
+
+done:
+ return 0;
+}
+
static int shmem_parser(const struct option *opt, const char *arg, int unset)
{
const u64 default_size = SHMEM_DEFAULT_SIZE;
@@ -339,18 +425,9 @@ static const struct option options[] = {
"Kernel command line arguments"),
OPT_GROUP("Networking options:"),
- OPT_STRING('n', "network", &network, "user, tap, none",
- "Network to use"),
- OPT_STRING('\0', "host-ip", &host_ip, "a.b.c.d",
- "Assign this address to the host side networking"),
- OPT_STRING('\0', "guest-ip", &guest_ip, "a.b.c.d",
- "Assign this address to the guest side networking"),
- OPT_STRING('\0', "host-mac", &host_mac, "aa:bb:cc:dd:ee:ff",
- "Assign this address to the host side NIC"),
- OPT_STRING('\0', "guest-mac", &guest_mac, "aa:bb:cc:dd:ee:ff",
- "Assign this address to the guest side NIC"),
- OPT_STRING('\0', "tapscript", &script, "
Re: [PATCH 1/2] nVMX: Add KVM_REQ_IMMEDIATE_EXIT
On Fri, Sep 23, 2011, Marcelo Tosatti wrote about "Re: [PATCH 1/2] nVMX: Add KVM_REQ_IMMEDIATE_EXIT": > On Thu, Sep 22, 2011 at 01:52:56PM +0300, Nadav Har'El wrote: > > This patch adds a new vcpu->requests bit, KVM_REQ_IMMEDIATE_EXIT. > > This bit requests that when next entering the guest, we should run it only > > for as little as possible, and exit again. > > > > We use this new option in nested VMX: When L1 launches L2, but L0 wishes L1 >... > > @@ -5647,6 +5648,8 @@ static int vcpu_enter_guest(struct kvm_v > > } > > if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu)) > > record_steal_time(vcpu); > > + req_immediate_exit = > > + kvm_check_request(KVM_REQ_IMMEDIATE_EXIT, vcpu); >... > The immediate exit information can be lost if entry decides to bail out. > You can do > > req_immediate_exit = kvm_check_request(KVM_REQ_IMMEDIATE_EXIT) > after preempt_disable() > and then transfer back the bit in the bail out case in > if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests Thanks. But thinking about this a bit, it seems to me that in my case *losing* this bit on a canceled entry is the correct thing to do, as turning on this bit was decided in the injection phase (in enable_irq_window()), and next time, if the reason to turn on this bit still exists (i.e., L0 has something to inject to L1, but L2 needs to run), we will turn it on again. -- Nadav Har'El|Sunday, Sep 25 2011, n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Guarantee: this email is 100% free of http://nadav.harel.org.il |magnetic monopoles, or your money back! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Qemu co-operation with kvm tsc deadline timer
>From 7b58c09d1bb70c7ca8aa29892b08ba4a3e7b9e92 Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Sun, 25 Sep 2011 15:48:29 +0800
Subject: [PATCH] Qemu co-operation with kvm tsc deadline timer
KVM add emulation of lapic tsc deadline timer for guest.
This patch is co-operation work at qemu side.
Signed-off-by: Liu, Jinsong
---
target-i386/cpu.h |4 +++-
target-i386/kvm.c | 14 ++
target-i386/machine.c |1 +
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 4a6f675..52d0da2 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -283,6 +283,7 @@
#define MSR_IA32_APICBASE_BSP (1<<8)
#define MSR_IA32_APICBASE_ENABLE(1<<11)
#define MSR_IA32_APICBASE_BASE (0xf<<12)
+#define MSR_IA32_TSCDEADLINE0x6e0
#define MSR_MTRRcap0xfe
#define MSR_MTRRcap_VCNT 8
@@ -687,6 +688,7 @@ typedef struct CPUX86State {
uint64_t async_pf_en_msr;
uint64_t tsc;
+uint64_t tsc_deadline;
uint64_t mcg_status;
@@ -947,7 +949,7 @@ uint64_t cpu_get_tsc(CPUX86State *env);
#define cpu_list_id x86_cpu_list
#define cpudef_setup x86_cpudef_setup
-#define CPU_SAVE_VERSION 12
+#define CPU_SAVE_VERSION 13
/* MMU modes definitions */
#define MMU_MODE0_SUFFIX _kernel
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 22b1dd0..ac8aa04 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -59,6 +59,7 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
static bool has_msr_star;
static bool has_msr_hsave_pa;
+static bool has_msr_tsc_deadline;
static bool has_msr_async_pf_en;
static int lm_capable_kernel;
@@ -568,6 +569,10 @@ static int kvm_get_supported_msrs(KVMState *s)
has_msr_hsave_pa = true;
continue;
}
+if (kvm_msr_list->indices[i] == MSR_IA32_TSCDEADLINE) {
+has_msr_tsc_deadline = true;
+continue;
+}
}
}
@@ -881,6 +886,9 @@ static int kvm_put_msrs(CPUState *env, int level)
if (has_msr_hsave_pa) {
kvm_msr_entry_set(&msrs[n++], MSR_VM_HSAVE_PA, env->vm_hsave);
}
+if (has_msr_tsc_deadline) {
+kvm_msr_entry_set(&msrs[n++], MSR_IA32_TSCDEADLINE, env->tsc_deadline);
+}
#ifdef TARGET_X86_64
if (lm_capable_kernel) {
kvm_msr_entry_set(&msrs[n++], MSR_CSTAR, env->cstar);
@@ -1127,6 +1135,9 @@ static int kvm_get_msrs(CPUState *env)
if (has_msr_hsave_pa) {
msrs[n++].index = MSR_VM_HSAVE_PA;
}
+if (has_msr_tsc_deadline) {
+msrs[n++].index = MSR_IA32_TSCDEADLINE;
+}
if (!env->tsc_valid) {
msrs[n++].index = MSR_IA32_TSC;
@@ -1195,6 +1206,9 @@ static int kvm_get_msrs(CPUState *env)
case MSR_IA32_TSC:
env->tsc = msrs[i].data;
break;
+case MSR_IA32_TSCDEADLINE:
+env->tsc_deadline = msrs[i].data;
+break;
case MSR_VM_HSAVE_PA:
env->vm_hsave = msrs[i].data;
break;
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 9aca8e0..25fa97d 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -410,6 +410,7 @@ static const VMStateDescription vmstate_cpu = {
VMSTATE_UINT64_V(xcr0, CPUState, 12),
VMSTATE_UINT64_V(xstate_bv, CPUState, 12),
VMSTATE_YMMH_REGS_VARS(ymmh_regs, CPUState, CPU_NB_REGS, 12),
+VMSTATE_UINT64_V(tsc_deadline, CPUState, 13),
VMSTATE_END_OF_LIST()
/* The above list is not sorted /wrt version numbers, watch out! */
},
--
1.6.5.6
qemu-tsc-deadline-timer.patch
Description: qemu-tsc-deadline-timer.patch
